HTTPS Inspection - Valid CA for inspection

[j_silva]

Hello everyone,

I would like to share with you the following issue that I am facing with at a client.

The environment has a simple cluster with 2 (two) members in HA mode. To better control internet surfing, we enabled SSL inspection. We were using a certificate generated by Active Directory and due to its expiration date being close, it was necessary to create a new one, however, this new certificate was generated by GlobalSign. The new certificate generated by GlobalSign was imported via Smartdashboard and when we validated internet access, the client reported that no website would open due to the firewall certificate error, according to below:

Below, the certificate that was imported to firewall and machines from environment:

In my opinion, this issue should not occur, since we imported a valid certificate to the firewall, the only difference being that the previous certificate was an internal CA (Active Directory).

I did not find any documentation that mentions that the certificate for SSL inspection must be from an internal CA and not from a valid CA. Could you explain why this issue occurs? Does this behavior make sense for you?

[the_rock]

Here is the way I look at it. I have ssl inspection lab in R81.20 and R82 and regardless what entity issues the certificate, as long as ALL certs from root CA and ssl cert are TRUSTED, there is no reason to give an error. happy to do remote and help you out.

Andy

[the_rock]

Forgot to say, make sure that cert shows up in legacy dashboard https inspection tab.

[PhoneBoy]

Did you include the entire certificate chain as part of the import?
This means the root CA plus intermediate certificates.

[Ryan_Ryan]

No this can't be right because no cert authority in the world will issue you a "CA" certificate, they will issue you a cert for server identification not for certificate authority. Please check your cert and see if it has Basic Constraints: CA:TRUE. If it does not then it cannot be used for https inspection (even if you did import it to the users pc cert store it will not work).

You need to issue the cert yourself and trust it, either install the cert in al the users trusted CA cert stores or have it signed by an existing trusted authority.

[the_rock]

Totally valid point.

[the_rock]

One could also argue that CA is TECHNICALLY cert authority : - )

[oa_munich]

As suggested already, your certificate is a server-signing organization validated certificate according to the name of the CA which issued it https://support.globalsign.com/ca-certificates/intermediate-certificates/organizationssl-intermediat...

For re-encryption of the connections, you'd need a CA certificate, not a server certificate.

GlobalSign offers a PKI service, where they would issue you a CA certificate, but it won't be trusted by devices by default, as it won't be issued by a root CA.

You'd need to distribute your new CA cert to devices.

[j_silva]

Good morning everyone,

Thank you very much for all the answers. I looked at them all and they have already helped me a lot.

For everyone's information, this certificate is being generated by the customer and I don't know how to describe to you how it is being done. I don't know the method used to generate the .p12 file and I don't know if the entire certificate chain is being imported.

So, to answer some questions, again, I don't know if the entire certificate chain is imported with the .p12 file and I don't know if there are basic restrictions on generating this certificate.

According to @the_rock , I also don't see any reason why it wouldn't work, but if you need more information like those mentioned by @PhoneBoy and @Ryan_Ryan , I understand that it really won't work correctly.

I also thanks for @oa_munich !

Guys, one last question, regarding the CA certificate chain, wouldn't this entire "base" of the certificate chain be present in the Manager?

[the_rock]

Maybe wording might not be 100% correct, but here is example in my lab. Think of mgmt as actual CA,if you will (certificate authority) and the actual "gw" cert as sub-CA that generates on the fly cert for the clients. I attached screenshots of all this and more than happy to show you in my lab.

Andy

 

 

 

[j_silva]

Thanks @the_rock 

Could you describe how did you generate the https certificate?

I think that you generated externally.

[the_rock]

What time zone are you in? Im in Canada EST. Lets do remote and I can show you my lab, so you can see...let me know.

Andy

[j_silva]

Hi @the_rock

Sorry, but yesterday was a holiday in Brazil.

I would be very welcome if we had a conference and you could show me your lab.

My timezone here is GMT-3 (Brazil time).

Today I will be available at 4pm GMT-3 or tomorrow at 10am GMT-3.

Please let me know if you are okay with it and don't mind my basic level of English.

[the_rock]

Dont worry, we all try to do proper grammar and spelling, but in IT world, no offense, people are NOT known for those things LOL

Anyway, you can message me directly and we can set something up. I think you are 2 hours ahead of me, as its 8.43 am here now, so its gmt-5 I believe.

Andy

[PhoneBoy]

We can tell quite a bit from the .p12 file itself.
You're welcome to send it to me (zipped) in a PM and I can have a look at it.

[j_silva]

Hi @PhoneBoy 

Yes, i can send you.

I´ll send you in couple minutes.

[j_silva]

Hi @PhoneBoy 

I have been sent the file to you.

[PhoneBoy]

As expected, the certificate provided is NOT a Certificate Authority certificate, but a wildcard certificate for your domain.
This certificate cannot sign certificates for other domains, which is required for HTTPS Inspection to function.

You need a Certificate Authority key to use HTTPS Inspection.
This can be generated from SmartConsole itself:

Or can be generated from any PKI (even via an OpenSSL command line).
A public CA (like GlobalSign) will NOT issue you a CA key that is globally trusted for this purpose.
The CA key must be explicitly configured on the clients as trusted (can be done through GPO or similar). 

[oa_munich · Accepted solution]

On Windows, there is a utility called certutil.exe

If you'd run this, 

certutil -v -dump C:\<your-ca-file>.p12 

and share the output, this will help troubleshoot further.

Specifically, there will be a section Certificate Extensions, and if you will find 1.3.6.1.4.1.311.20.2: Certificate Template Name (Certificate Type): CA or SubCA - it is a kind of a certificate you need.

If it is a server certificate (as I am suspecting), you will find a section 

2.5.29.37: Enhanced Key Usage
Server Authentication (1.3.6.1.5.5.7.3.1)

or

Client Authentication (1.3.6.1.5.5.7.3.2)

then it is the wrong kind of certificate, and you'll need a CA-one.

[the_rock]

Its been ages since I used that tool, but really glad you mentioned it, certainly may help in troubleshooting this.

Andy

[j_silva]

Hi @oa_munich 

Thanks a lot. I´ll check this information and i let you know soon.

[j_silva]

Hi, everyone

Just to let you know that the client is still not jealous of the correct certificate (and doesn't know when he will get it).

@oa_munich  your last information helped a lot to clarify the details of the certificate and to be sure that that certificate was not the correct one.

I thank everyone for their help, all the information posted helped me a lot.

Thank you.

[CaseyB]

If the client is generating it, they need to follow this process for third-party: 

sk165856 - How to create a Subordinate CA for HTTPS Inspection

I didn't see this mentioned yet.