topic Re: SSL decryption - Forward UNtrust certificate presented in General Topics

SSL decryption - Forward UNtrust certificate presented

oschuler — Wed, 05 Dec 2012 16:57:53 GMT

Hello,

We experienced a problem with a specific SSL encrypted site: https://panakeia.infoman.de/

The original certificate is issued to "*.infoman.de" and was issued by Go Daddy (--> InfomanCert_Original.png). It seems to be perfectly valid but still our PA-2050 thinks different and presents our internal clients a SSL certificate issued by our "Forward Untrust" CA certificate (--> InfomanCert_Untrusted.png).

Does anyone know how we can troubleshoot this issue? The logs doesn't reveal much information...

Thank you,

Oliver

Re: SSL decryption - Forward UNtrust certificate presented

oschuler — Wed, 05 Dec 2012 17:04:06 GMT

Addendum:

We already tried to import the Go Daddy Root CA but still got the same certificate error. Also it seems not to be related to Go Daddy certificates. If we open https://www.godaddy.com (which has exactly the same chain-of-trust as the Infoman certificate), the firewall decrypts perfectly right and presents the browser the correct "Forward Trust" certificate.

Original Certificate	PA created "Forward Trust" Certificate

Re: SSL decryption - Forward UNtrust certificate presented

mikand — Wed, 05 Dec 2012 22:31:09 GMT

It seems that (at least PANOS 5.0.0) have the root cert named "Go Daddy Class 2 Certification Author" but not the intermediate cert which issued the cert for the above site named "Go Daddy Secure Certification Authority".

I guess when you import the intermediate cert you need to have the root cert in the same pem file for it to be successful.

Unfortunately I always forgets if its root first and then intermediate or the other way around. I mean if the pem file should have this structure (or the other way around):

---PUBLIC CERT (root)---

text

---END PUBLIC CERT---

---PUBLIC CERT (intermediate)---

text

---END PUBLIC CERT---

Re: SSL decryption - Forward UNtrust certificate presented

oschuler — Wed, 05 Dec 2012 23:00:32 GMT

I will try that tomorrow, thank you. But if that works I can still not explain myself why SSL decryption works for https://www.godaddy.com but not for https://panakeia.infoman.de. They both have the same Root and also the same Intermediate certificate in the chain...

Re: SSL decryption - Forward UNtrust certificate presented

mikand — Wed, 05 Dec 2012 23:19:27 GMT

Uhm yeah...

Could it be that PA have some bug where "whatever.example.com" wont match a wildcard cert issued for "*.example.com" since "whatever" != "*" ?

The only differences I could pick up between the two certs (since both intermediate and root cert was the same):

[*.infoman.de]

http://crl.godaddy.com/gds1-28.crl

2.16.840.1.114413.1.7.23.1:

Certification Practice Statement pointer:

https://certs.godaddy.com/repository/

DNS Name: *.infoman.de

DNS Name: infoman.de

[www.godaddy.com]

http://crl.godaddy.com/gds3-61.crl

2.16.840.1.114413.1.7.23.3:

Extended Validation (EV) SSL Server Certificate

Certification Practice Statement pointer:

http://certificates.godaddy.com/repository/

DNS Name: www.godaddy.com

DNS Name: godaddy.com

Re: SSL decryption - Forward UNtrust certificate presented

oschuler — Thu, 06 Dec 2012 06:41:59 GMT

Exactly. I thought of such a problem as well and tested another site (OWASP) with a wildcard certificate which also works perfectly well 🙂 It is issued also by the same two Go Daddy CAs like the other two examples. That leads me to the only conclusion that the culprit must be somewhere inside the PA. For an unknown reason the PA thinks the original certificate presented by the Infoman server is invalid and issues a "Forward Untrust" certificate...

Maybe time to open a bug report?

Re: SSL decryption - Forward UNtrust certificate presented

oschuler — Mon, 10 Dec 2012 11:34:20 GMT

Another example:

https://www.tradepayablesservices.com

Original Certificate	PA created "Forward UNTRUST Certificae"

Re: SSL decryption - Forward UNtrust certificate presented

oschuler — Tue, 11 Dec 2012 19:02:51 GMT

We opened a ticket. The PA engineer replied with the following explanation:

The two mentioned websites don't deliver the complete certificate chain with their SSL negotiation. This can be verified with the following command:

openssl s_client -connect <URL>:443 -showcerts

A possible workaround is to import the intermediate certificate and mark it as "Trusted Root CA" on the firewall.