When encountering SSL/TLS certificate validation issues where some clients succeed while others fail, we're typically dealing with intermediate certificate trust chain problems. The key observation here is that clients with different root stores or caching behaviors will validate certificates differently.

# Example OpenSSL command to verify certificate chain
openssl verify -CAfile full-chain.pem your-certificate.pem

Modern browsers maintain their own certificate stores, and some may have cached intermediate certificates while others haven't. The SEC_ERROR_UNKNOWN_ISSUER error specifically indicates that the client cannot build a complete trust path to a known root certificate.

# Sample Nginx configuration to ensure proper chain delivery
server {
    listen 443 ssl;
    ssl_certificate /path/to/fullchain.pem; # Contains server cert + intermediates
    ssl_certificate_key /path/to/privkey.pem;
    ssl_trusted_certificate /path/to/root.crt; # Optional root for OCSP stapling
}

To properly diagnose this issue, we need multiple validation tools:

• Use OpenSSL's s_client to inspect the presented chain
• Check against multiple root stores (Mozilla, Microsoft, Apple)
• Test from different geographical locations

openssl s_client -connect yourdomain.com:443 -showcerts

1. Ensure your web server delivers the complete certificate chain
2. Include all necessary intermediate certificates
3. Verify your certificate bundle order (server cert first, then intermediates)
4. Check for proper Content-Type headers (application/pkix-cert)

SSLCertificateFile /etc/ssl/certs/your_domain.crt
SSLCertificateKeyFile /etc/ssl/private/your_domain.key
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

Different browsers handle certificate validation differently:

• Chrome uses the OS certificate store on Windows but maintains its own on other platforms
• Firefox maintains its own certificate store (Mozilla's CA Certificate Program)
• Safari uses the macOS keychain

Before concluding the fix is complete, verify using:

# Check from multiple SSL validation services
curl -v https://yourdomain.com
curl --cacert /path/to/custom-ca.pem https://yourdomain.com

Use online validators like SSL Labs' SSL Test to verify your configuration from multiple perspectives.

After our hosting provider reissued the SSL certificate for bilingueanglais.com following an expiration mishap, most users regained HTTPS access. However, approximately 3-5% of visitors across various platforms continue receiving "Your connection is not secure" errors, particularly the SEC_ERROR_UNKNOWN_ISSUER message in Firefox.

The DigiCert SSL checker revealed the core issue: missing intermediate certificates in the certificate chain. This creates inconsistent validation because:

Certificate Chain:
  1. Domain Certificate (Present)
  2. Intermediate CA (Missing for some clients)
  3. Root CA (Trusted by all modern browsers)

Modern browsers employ certificate caching and OCSP stapling mechanisms differently. Chrome (v79+) may successfully validate through cached intermediates, while Firefox might strictly require the complete chain. Server configuration plays a critical role:

// Apache configuration requiring correction
SSLCertificateFile /path/to/certificate.crt
SSLCertificateKeyFile /path/to/private.key
# Missing chain file causes validation failures
SSLCertificateChainFile /path/to/intermediate.crt

To diagnose the complete chain presentation:

openssl s_client -connect bilingueanglais.com:443 -servername bilingueanglais.com -showcerts

Proper output should show 2-3 certificates (domain, intermediate, possibly root). If only one appears, the chain is incomplete.

For Apache servers:

# Correct SSL configuration
SSLCertificateFile /etc/ssl/certs/domain.crt
SSLCertificateKeyFile /etc/ssl/private/domain.key
SSLCertificateChainFile /etc/ssl/certs/intermediate_bundle.crt

For Nginx servers:

ssl_certificate /etc/ssl/certs/domain_with_chain.crt;
ssl_certificate_key /etc/ssl/private/domain.key;

The chain file must contain intermediates in correct order (server cert first, then intermediates):

-----BEGIN CERTIFICATE-----
[Domain Certificate]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Intermediate CA]
-----END CERTIFICATE-----

Even after fixing the chain, some legacy systems may still report errors due to:

• Outdated root certificate stores (Windows XP systems)
• Enterprise systems with customized trust stores
• Mobile devices with expired pre-installed roots

To verify certificate installation comprehensively:

testssl.sh -U --sneaky https://bilingueanglais.com