Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
Certificate pinning was developped to help prevent man in the middle attack.
But what is the Certificate Pinning?
Traditionally, SSL Handshake consists on the validation of the server’s certificate, let’s say collab.com. The validation is done using the CA’s certificate located in the certificate store of the web browser.
The certificate store contains several CA Certificates, may be more than 100.
If at least one CA delivers by mistake or more likely to conduct an attack a valid certificate for example *.collab.com, attackers are able to launch a Man In The Middle Attack.
in order to prevent this attack, it is possible to use the SSL protocol in another way, by creating an association between the domain name of a site (www.collab.com) and the certificate or certification authority expected. Thus, only the a certificate (of collab.com) signed by one of the specific certification authorities will be accepted and if the certificate of collab.com signed by another CA is presented, it is not trusted.
Certificate pinning can be explained with a simple words: Is this connection secure with a valid certificate and is it signed by the CA I’m expecting?.
Some applications use a technique referred to as TLS/SSL pinning or certificate pinning, which embeds the fingerprint of the original server certificate in the application itself. As a result, if you configured a TLS/SSL rule with a SSL Forward Proxy action, and this rule matches this traffic, when the application receives a resigned certificate from Palo Alto Firewall the validation fails and the connection is aborted.
In the capture wireshark from the client side connection or the application you can detect this failed validation with the TLS alert message , The Alert Message indicates the spoofed re-signed certificate is not recognized by the application because the application is expecting to receive and validate only server certificate signed by a specific CA (Certification Authority) but it is receiving the server certificate signed by the Firewall, finally a TCP Reset is sent by the application to close the TCP connection.
If your browsers or your applications uses certificate pinning to verify a server certificate, you cannot decrypt this traffic by re-signing the server certificate.
To allow access to the website that uses a certificate pinning, you can add the hostname of the server in the SSL Decryption Exclusion List. The hostname is compared to the SNI in the Client Hello Message and the Common Name in the Server Certificate, if a match is found the firewall excludes the traffic from decryption.
