A legacy application fails to connect to a custom domain using an Okta-managed certificate after an automatic certificate renewal. This issue occurs because of a certificate pinning failure when Let's Encrypt updates its issuance chains. Resolve this issue by verifying the application certificate pinning configuration and updating it to use Subject Public Key Info (SPKI) pinning with backup pins. The application fails to establish a secure connection and drops the connection after Okta completes the certificate renewal.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Custom Domains
• Okta-managed certificates
• Let's Encrypt

Let's Encrypt updates its issuance chains, introducing newer intermediate and root hierarchy elements (such as YR/YE). If the application pins the exact leaf certificate, a specific intermediate certificate, issuer name, certificate serial number, or the full certificate fingerprint, the application fails to connect. This failure occurs even if the renewed certificate remains valid and browsers and standard Transport Layer Security (TLS) clients trust it.

How is the certificate pinning failure resolved?

Verify the exact certificate pinning configuration of the application and update the pinning method to resolve the connection failure.

1. Verify if the application pins the leaf certificate fingerprint. If it does, update the fingerprint upon every renewal.
2. Check if the application pins a Let's Encrypt intermediate certificate (such as R10/R11, R12, or R13). The connection fails when the renewed certificate chains through YR or YE.
3. Implement Subject Public Key Info (SPKI) pinning with backup pins instead of pinning the entire certificate if pinning is strictly required.
4. Confirm that the server presents the full certificate chain rather than only the leaf certificate.

How is the certificate chain validated?

Run the following OpenSSL command to validate the certificate chain and compare the results from before and after the renewal, paying special attention to the leaf certificate fingerprint, issuer, intermediate Common Name (CN), and SPKI hash.

openssl s_client -connect <hostname>:443 -servername <hostname> -showcerts

Related References

• Let's Encrypt - New Generation Y Hierarchy of Root and Intermediate Certificates
• Let's Encrypt - Certificates / Chain of Trust
• Let's Encrypt - Deploying Let's Encrypt's New Issuance Chain