How to Validate an SSL Certificate

Checking an SSL certificate and validating it are two different things. Checking tells you the certificate exists and shows you its fields. Validation tells you the certificate is correctly installed, trusted by clients, and actually securing the connection properly. A certificate can exist and still fail validation in a dozen ways. Here's how to validate everything that matters.

What SSL Validation Actually Means

When a browser connects to your site over HTTPS, it performs several validation steps automatically. If any step fails, the browser shows an error. Validating your certificate means running these same checks yourself -- proactively -- to catch problems before browsers (and users) do.

The five areas of validation:

1. Domain validation -- Does the certificate match the domain being accessed?
2. Chain validation -- Is the full certificate chain present and correct?
3. Trust validation -- Is the root CA trusted by browsers and operating systems?
4. Protocol validation -- Are the TLS version and cipher suites secure and compatible?
5. Transparency validation -- Is the certificate logged in Certificate Transparency logs?

1. Domain Validation (Hostname Matching)

The certificate must cover the exact domain being accessed. This is checked against the Subject Alternative Names (SANs) field, not the Common Name.

Check it with OpenSSL:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Output:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

Common hostname validation failures:

• Accessing www.example.com but the cert only covers example.com
• Accessing a subdomain like api.example.com not listed in SANs
• Using a wildcard cert (*.example.com) but accessing the bare domain (example.com) -- wildcards don't cover the apex
• Using a wildcard cert but accessing a multi-level subdomain (sub.api.example.com) -- wildcards only match one level

2. Chain Validation (Intermediate Certificates)

A valid certificate chain goes: Leaf certificate (your domain) -> Intermediate certificate(s) -> Root CA certificate. If any link is missing, validation fails in some clients.

Check the chain:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null

Look at the certificate chain section near the top of the output:

Certificate chain
 0 s:CN = example.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

You should see at least two entries (leaf + intermediate). If you only see one, the intermediate is missing.

Verify the chain explicitly:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep "Verify return code"

• Verify return code: 0 (ok) -- Chain validates successfully
• Verify return code: 21 (unable to verify the first certificate) -- Missing intermediate
• Verify return code: 20 (unable to get local issuer certificate) -- Root not in local trust store
• Verify return code: 2 (unable to get issuer certificate) -- Broken chain

Why this matters: Chrome often works even with a broken chain because it caches intermediate certificates and can fetch missing ones via Authority Information Access (AIA). Firefox, curl, mobile apps, and API clients don't. A site that "works in Chrome but not Firefox" almost always has a chain problem.

3. Trust Validation (Root CA)

The root CA at the top of the chain must be in the client's trust store. Every browser and operating system ships with a list of trusted root CAs.

How to check: The Verify return code: 0 (ok) from OpenSSL confirms root CA trust (using your system's trust store). For a more thorough check, use Qualys SSL Labs.

Common trust failures:

• Self-signed certificates -- Not trusted by any browser unless manually added
• Private/internal CAs -- Only trusted on machines that have the CA cert installed
• Distrusted CAs -- Some CAs have been removed from trust stores (e.g., certain Symantec roots in 2018). Certificates from these CAs will fail validation even if they haven't expired.

4. Protocol Validation (TLS and Cipher Suites)

A valid certificate on an insecure protocol is still an insecure connection. Protocol validation checks that your server supports modern TLS and strong ciphers.

What to check:

• TLS version: Must support TLS 1.2 at minimum. TLS 1.3 is preferred. TLS 1.0 and 1.1 are deprecated and rejected by modern browsers.
• Cipher suites: Should use AEAD ciphers (AES-GCM, ChaCha20-Poly1305). Avoid RC4, 3DES, and CBC-mode ciphers.
• Key exchange: Should use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for forward secrecy.
• Certificate key size: RSA 2048-bit minimum. ECDSA P-256 is the modern alternative.

Test with OpenSSL:

# Check negotiated protocol and cipher
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher"

# Test specific TLS version
openssl s_client -connect example.com:443 -tls1_2 </dev/null 2>/dev/null | head -5
openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null | head -5

The definitive test: Qualys SSL Labs.

Go to ssllabs.com/ssltest and enter your domain. SSL Labs runs a comprehensive battery of tests and gives you a letter grade:

SSL Labs also checks for specific vulnerabilities like BEAST, POODLE, Heartbleed, and DROWN. It's the most comprehensive free validation tool available.

5. Certificate Transparency (CT) Validation

Certificate Transparency is a system of public logs where CAs must record every certificate they issue. This prevents CAs from issuing certificates fraudulently (or by mistake) without anyone knowing.

Why it matters: Since 2018, Chrome requires all publicly trusted certificates to have Signed Certificate Timestamps (SCTs) proving they were logged. Certificates without SCTs will show an error in Chrome.

Check CT compliance:

Firefox's certificate viewer shows SCTs in the certificate details. You can also check CT logs directly:

• crt.sh (crt.sh) -- Search for certificates issued for any domain. Useful for discovering certificates you didn't know existed (which could indicate a compromise or unauthorized issuance).
• Google CT Search -- Google's Certificate Transparency log search tool.

# Check for SCTs in the certificate
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A 5 "CT Precertificate"

Validation Checklist

Use this checklist to validate any SSL certificate thoroughly:

Validation is a point-in-time check. It tells you that right now everything is correct. Certificates expire, configurations change, and CAs get distrusted. For ongoing confidence, pair validation with continuous monitoring that runs these checks for you on a schedule.

A certificate that passes validation today can fail tomorrow. Validate once, then monitor forever.