HTTPS inspection certificate question

[the_rock]

Hey guys,

Im wondering if someone can confirm if this indeed is expected CP behavior when https inspection is on. So, customer and I turned blade on, we created custom cert on https insp. tab and gave it 10 year validity, exported, tested and block page comes up fine...

BUT...here is what Im wondering. I set up https inspection few times and quite honestly, never paid attention to this part, but client is wondering, when page is blocked, when you click little sign to see the cert presented, we see cluster VPN certificate showing and obviously says issued by mgmt server, which makes sense, since thats internal CA. Is that expected?

I ask, because, when customer asked me about it, I figured it was indeed expected, but then more I thought about it, more Im wondering if thats the case. Isnt actual cert created from https inspection tab valid for 10 years assigned, supposed to show, instead of cluster vpn cert? By the way, I checked this on another environment where inspection is on and behavior is the same, block page shows actual fw vpn cert. 

I know for a fact if you do this on Fortinet or Cisco (Im sure PAN is the same), users would see actual cert created, not anything else, so I have a gut feeling on CP it might be different, as its signed by mgmt (being ICA), but confusing part is why the actual fw vpn cert shows up?

We have TAC case about it, but had not gotten useful response yet. If anyone could clarify, would be awesome. I could not really find any sort of documentation stating whether this is expected or not.

Tx as always!!

[Sorin_Gogean]

hey yhe_rock,

the "when page is blocked, when you click little sign to see the cert presented, we see cluster VPN certificate showing and obviously says issued by mgmt server" is expected as the block page comes from the cluster portal and that is shown with the SSL certificate that you generated for the cluster. 

it's totally different than the CA you did for the HTTPS inspection.

let's recap 🙂 . for HTTPS Inspection/decryption, you generated an sub-CA (you delegated Checkpoint from your internal CA) that will generate on the fly certs for the HTTPS traffic that reaches your clients. The https from the cluster/gw is like every other webserver, generated for a bit more than 1 year, and has nothing to do with the sub-CA you have installed for HTTPS Inspection/decryption .

hopefully is clearer now, let me know and I can explain better.

Ty,

PS: from my notes :

"

We require an SSL certificate on the GW's as the page presented with the BLOCK message, is HTTPS and is using the Platform Portal (as it seems) .

They say to follow :https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

But it’s better to follow :https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

(as I've use it previously )

"

[_Val_]

Second that👆🏻HTTPSi cert is different from portal/GW cert. 

[CheckPointerXL]

Hello Val,

I created a SubCA certificate signed by customer's Microsoft CA like suggested by sk165856.

Now we need to enable clients out of domain for inspection. Of course we need to manually install Root CA inside "Trusted Root Certification Authority". My doubt is: do we need to manually install also the signed SubCA ? If so, this should be installed inside  "Trusted Root Certification Authority" or inside "Intermediate Certification Authority"? 

Thank you!

[PhoneBoy]

Installing all the relevant CAs (root/sub) on the client is necessary, yes.
I assume you'd install the intermediate CA in the similarly named part of the certificate store, yes.

[the_rock]

Ok, I get that part, but...is there any way that when people get block page they see the cert generated from https inspection tab? Thats the end goal.

[Sorin_Gogean]

Like Wolfgang showed, the Block page uses the Cliuster GW certificate you set on UserCheck .

They can be from the same CA, but my assumption is that you used a self-signed CA for HTTPS Inspection, therefore you don't have a higher CA that can be used to sign other certificates (like the UserCheck one) and therefore you get this problem . Am I right ?

[the_rock]

Right, we tried using something else, but problem is we could not convert it to .p12 format. Obviously, you cannot use cert generated from https inspection tab in user check tab, since it has .cer format.

[Sorin_Gogean]

I don't see it as the website certificate is available in any browser, just go to the UserCheck portal and save the cert (that one with the VPN) .

Whatever type of certificate format you get you'll be able to import on clients and trust it.

Not sure I follow the p12 requirement, as the p12 would also include a key, and this is not the case here. 

Can you get some screens or a doc showing step by step what you do and where you get stuck, maybe I miss seeing something in your explications 😞 .

[the_rock]

No worries @Sorin_Gogean , you actually helped a LOT, I greatly appreciate. I have much better understanding of this now, because quite honestly, I never paid much attention to it before. What Im referring to is even in block page tab @Wolfgang posted, you can ONLY upload .p12 cert, thats it, no other format.

I believe solution to all of it is sk165856

How to create a Subordinate CA for HTTPS Inspection 

[Sorin_Gogean · Accepted solution]

Got it now, still I come back to what I stated before, your client should have an internal CA authority that can delegate a sub-CA for the HTTPS inspection, and sign CSR's for the webservers - like the UserCheck . 

Otherwise I see a headache with getting all certs on clients whenever is needed, when you can just have the internal CA trust and that's all. 

And I guess there are some free CA solutions out-there, or use Microsoft one (if they have AD deployed)  .

PS: for the certificate generation, in my notes I also pointed out that for the block page and anything else, should add those URL's as additional SAN's to the cert.... so have that in mind.

[the_rock]

Thanks a lot, I think that helps big time. Ah, certs have never been my favorite subject when it comes to any vendor : - )

[the_rock]

Hey @Sorin_Gogean . I wanted to ask something else related to this...so customer ended up putting new cert from their own CA for user check and its trusted. They also generated https cert for clients valid for 10 years and installed it on client machine, but they still see block page showing cert is NOT trusted. I dont understand that...they imported both certs as trusted into test PC and no luck. We even had TAC person on the phone, showed them the behavior, they had customer open legacy https dashboard, import both certs, no joy. Maybe Im looking at this totally wrong way, but if certs are trusted, isnt block user check page supposed to reflect that and NOT show that cert is untrusted? We even see when clicking on little lock sign that it is trusted and user check tab does not say that cert is not trusted. I dont get it...

[Wolfgang]

@the_rock I‘ll try to explain some more what to do..

First for https inspection you have to create a SubCA from an internal RootCA of your choice. These SubCA has to be imported to the HTTPS inspection. This will be the CA which creates new certificates for every inspected website. Your clients have to trust these internal RootCA to avoid browser warnings, you need to have to import and trust these RootCA on all your clients.

Secondly, if a website will be blocked and your clients get presented the usercheck page. This will be a https connection to the gateway. Your client/browser has to trust the CA of the shown website. This will be the certificate which you have to install on the usercheck configuration. Create a certificate for a Webserver from an internal RootCA and import these to the usercheck configuration. Same like before, your clients have to trust these RootCA, you need to have to import and trust these RootCA on all your clients.

You can create the needed SubCA and webserver certificate from different RootCA, but normally you get both from the same internal RootCA. And again, it‘s important that your client have to trust the RootCA! You have to import RootCA and SubCAs on your clients to trust them, not certificates for clients. And you have to store them in the right certificate store like for root or intermediate CAs.

[the_rock]

• Thats 100% what was done and customer showed it to TAC and they verified it was good, but still no luck. We are awaiting feedback from TAC.

[Sergej_Gurenko]

Hello @Wolfgang, for the environments with multiple Security clusters, is there any point in generating individual, per-cluster HTTPS SubCA certificates? It looks like the same SubCA certificate can go to _ALL_ clusters. Asking this for some future project...

[Wolfgang · Accepted solution]

@Sergej_Gurenko you can use the same SubCA on all your clusters, no problem. If you want to see which cluster creates the new certificates you have to use different SubCAs.

[Sorin_Gogean]

Hey @the_rock , let me see if I get it correctly 🙂 

You say "...so customer ended up putting new cert from their own CA for user check and its trusted. They also generated https cert for clients valid for 10 years and installed it on client machine...."  - so the Client cert valid for 10years, is installed on Clients and has nothing to do with the HTTPS Inspection or anything else, you can only use it for client network authentication, but nothing else.

"they still see block page showing cert is NOT trusted" & " We even see when clicking on little lock sign that it is trusted and user check tab does not say that cert is not trusted. I dont get it..." - can you please get me some full screenshots - just mark all that should not be seen and post them - as I also have a HARD time seeing it.

..... working to get some screenshots how things are configured from our side - maybe it will be an eye opener ?!?!?!?!

So you see in CPBlock that we don't allow some site - High Risk - and the CKP Log messages....
Now on that redirect, we use the UserCheck certificate that we added to the cluster - see the 3rd screenshot..... 
....also have a look on the CKPSAN's so you have the ideea of the cert we use.....

If we go to a site that get's inspected, we get the cert generated on-the-fly by the CheckPoint SubCA... See CKPInspectA and B and the installed SubCA CKPCert....

Let me know if this answers your question of you still have some ...

PS: just dropped an ideea, are you using IP's in the UserCheck URL and your certificate has only FQDN's in it ???? 

[the_rock]

Thanks so much @Sorin_Gogean for your indepth answer, means a lot! I will see if we can get some screenshots. Customer is using fqdn in user check tab snd it fully resolves to external VIP, as its supposed to.

[the_rock]

Turns out SAN (Subject Alternative Name in the certificate)  was missing : - (. Now its working as expected!! Thanks SO MUCH @Wolfgang @Sorin_Gogean @skandshus @_Val_ . I dealt with https inspection before, but I learned so much more from this problem. I appreciate all of you!

[Wolfgang]

You can convert certificates from one format to another’s  with openssl. I‘m not sure about the exact syntax but something like this one „openssl pkcs12 -export -in yourcertificate.cer -inkey yourkey.key -out yourcertificate.pfx“.

In GAiA you can use cpopenssl, that’s the Check Point version of this tool.

Additional, there are some websites with tools available doing this if you want to convert your certificates from a cloud service.

[the_rock]

No, thats true, but even being with TAC on the phone for close to 2 hours the other day, we could not get it done, so I have a gut feeling there was a flag missing somewhere...

[Wolfgang]

The block page shown from URL-Filter is the usercheck page. The used certificate for this website will be a default one created by the internal CA. You can import your own here and your clients should trust them. You can check this page via the shown settings "Main URL"

[skandshus]

They use different certificates.. the HTTPS inspections and the "other blades" 🙂

that's why you see  it..

you "just" need to change it.. i've done it on my own setups.