SSL decryption - Forward UNtrust certificate presented

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

SSL decryption - Forward UNtrust certificate presented

L4 Transporter

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

1 accepted solution

Accepted Solutions

L4 Transporter

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.

View solution in original post

7 REPLIES 7

L4 Transporter

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 CertificatePA created "Forward Trust" Certificate
GoDaddy_Original.pngGoDaddy_Trusted.png

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---

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...

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

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?

L4 Transporter

Another example:

https://www.tradepayablesservices.com

Original CertificatePA created "Forward UNTRUST Certificae"
GE_original_valid_cert.pngGE_invalid_cert.png

L4 Transporter

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.

  • 1 accepted solution
  • 8991 Views
  • 7 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!