- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-05-2012 08:57 AM
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
12-11-2012 11:02 AM
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.
12-05-2012 09:04 AM
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 |
---|---|
12-05-2012 02:31 PM
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---
12-05-2012 03:00 PM
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...
12-05-2012 03:19 PM
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
12-05-2012 10:41 PM
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?
12-10-2012 03:34 AM
Another example:
https://www.tradepayablesservices.com
Original Certificate | PA created "Forward UNTRUST Certificae" |
---|---|
12-11-2012 11:02 AM
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.
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!