Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
the_rock
Legend
Legend
Jump to solution

Https inspection inquiry

Hi guys,

 

Sorry if Im posting this into the wrong board. Happy holidays everyone (first of all) and hope you are staying safe and healthy. Just wondering about something, maybe someone can clarify this for me...

So, customer and myself uploaded a trusted 3rd party certificate (Digicert) for https inspection and then TAC helped us confirm its valid via legacy dashboard as well. Now, maybe Im confused about this, but I was pretty sure if its a valid trusted 3rd party cert than people would not have to follow sk69660 or distribute it to all PCs browsers in order to avoid browser warnings when going to blocked categories, but sadly, that does not seem to be working.

 

Not sure what Im missing here, but we were told the same by TAC as well. I would really appreciate if someone could tell us the right steps to make this work.

 

Thanks in advance!

 

Andy 

0 Kudos
1 Solution

Accepted Solutions
Bob_Zimmerman
Authority
Authority

To be clear, you should use the root CA to sign a branch CA, which can then sign leaf certificates. This branch CA should be put on the firewalls. The leaf certificates would be trusted by anything which trusts the root CA.

Putting the actual AD root CA on the firewalls has complicated security implications, as firewalls present a different attack surface from a domain controller (more shared passwords, but generally fewer people know those passwords). A branch CA has fewer security implications, as it can be revoked if you are concerned about compromise. For example, if you have to adversarially fire somebody who had administrative access to the firewalls, you should rotate signing keys which they may have been able to access. Rotating a root CA is enormously painful.

View solution in original post

9 Replies
_Val_
Admin
Admin

It should be a root CA certificate from Digicert, with the private keys, which is able to sign other certificates, just no a regular one. With that comes the chain validation. Most browsers will try to validate the following:

  • server cert signed by CA
  • CA root cert signed by Digicert
  • Digicert itself

If any of these validations fail on the client, you will have "untrusted". Most important is the second part. Your root cert should be trusted by all your clients till you move forward safely. 

the_rock
Legend
Legend

Thanks Val...Im pretty sure thats what it is, but let me confirm with customer.

 

Andy

PhoneBoy
Admin
Admin

We are in the process of simplifying the forum structure a bit, which will hopefully make finding the right forum easier in the future 🙂

For HTTPS Inspection purposes, we need a CA certificate capable of signing certificates.
No globally trusted CA will issue you a CA certificate for this purpose.
In fact, it’s explicitly against their terms of service to use it for those purposes.
CA that are known to do this tend to get blacklisted by browser and OS manufacturers fairly quickly.

You can certainly use an enterprise-wide CA certificate for HTTPS Inspection purposes, but nothing that would be globally trusted by every browser by default.

the_rock
Legend
Legend

Yea, I get that part : ). I was just hoping there was maybe an easier way to make this work without importing the cert to everyone's browser, but I guess not...

0 Kudos
_Val_
Admin
Admin

You could use your own AD root cert. Usually it is trusted on all managed PCs

the_rock
Legend
Legend

Thats not a bad suggestion actually...I will bring that up to them. Thanks!

0 Kudos
_Val_
Admin
Admin

When doing so, make sure the cert includes the whole chain and private keys, and AD CRL distribution is also working. If AD is several years old, when exporting the cert, use the best encryption hash available on AD.

Bob_Zimmerman
Authority
Authority

To be clear, you should use the root CA to sign a branch CA, which can then sign leaf certificates. This branch CA should be put on the firewalls. The leaf certificates would be trusted by anything which trusts the root CA.

Putting the actual AD root CA on the firewalls has complicated security implications, as firewalls present a different attack surface from a domain controller (more shared passwords, but generally fewer people know those passwords). A branch CA has fewer security implications, as it can be revoked if you are concerned about compromise. For example, if you have to adversarially fire somebody who had administrative access to the firewalls, you should rotate signing keys which they may have been able to access. Rotating a root CA is enormously painful.

the_rock
Legend
Legend

Thanks to everyone for responding, I appreciate it. One thing we also have to consider is that this is cloud mgmt instance, so using guidbedit is really more complicated than regular smart-1 for example, so having to make any database change is a bit risky, as if something breaks, we dont have ssh or web UI access, so relying on TAC at that point is an only option and there seems to be only 2-3 people in whole Check Point that have proper backend access to it. Anyway, I gathered all the notes you guys shared and we will have internal discussion and see best way to move forward.

 

Thanks again and happy New Year!

 

Andy

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events