SSL Certificate Security Checklist: Beyond the Green Padlock

A green padlock in the browser bar means your site has an SSL certificate. It does not mean your SSL configuration is secure. Expired certificates, outdated TLS versions, weak cipher suites, and missing HSTS headers are just a few of the issues that can leave your "secure" site wide open to attack. Here is the complete SSL security checklist you need in 2026.

Why the Green Padlock Is Not Enough

When browsers show a padlock icon, they are confirming one thing: the connection between the browser and the server is encrypted. That is a necessary baseline, but it tells you nothing about the quality of that encryption. A site can display a padlock while using TLS 1.0, a certificate that expires tomorrow, a self-signed certificate with no chain of trust, or cipher suites that were broken years ago.

Attackers know this. Tools like SSL Labs and Shodan make it trivial to scan the internet for servers with weak TLS configurations. If your server supports TLS 1.0, an attacker can force a downgrade attack. If your certificate chain is incomplete, mobile browsers may reject the connection entirely. If you lack HSTS, a man-in-the-middle can strip the HTTPS and serve the site over plain HTTP.

Use our SSL Checker to test your certificate right now, or run the Exposure Checker for a comprehensive security scan that includes SSL analysis.

1. Certificate Expiry and Renewal

The most common SSL failure is embarrassingly simple: the certificate expires. Let's Encrypt certificates last 90 days. Commercial certificates typically last one year (the CA/Browser Forum reduced the maximum to 398 days in 2020). When a certificate expires, browsers show a full-page warning that destroys user trust and blocks access.

How to check expiry from the command line

# Check certificate expiry date
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -dates

# Output:
# notBefore=Jan 15 00:00:00 2026 GMT
# notAfter=Apr 15 23:59:59 2026 GMT

# Check days until expiry
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -checkend 2592000
# Returns exit code 1 if cert expires within 30 days (2592000 seconds)

Best practices for certificate renewal

• Automate renewal with certbot or ACME clients. Manual renewal is a ticking time bomb. Set up certbot renew --deploy-hook to automatically reload your web server.
• Monitor expiry with alerts. Set alerts at 30, 14, and 7 days before expiry. Use our SSL Checker to verify expiry dates.
• Test renewal in staging first. A broken renewal process is worse than no automation at all.
• Track all certificates in an inventory. Organizations with dozens of domains lose track of certificates on forgotten subdomains. Those expired certificates become attack vectors.

2. TLS Protocol Versions

Not all TLS versions are created equal. As of 2026, you should only support TLS 1.2 and TLS 1.3. All earlier versions have known vulnerabilities:

• SSL 2.0 and SSL 3.0: Completely broken. POODLE attack (2014) was the final nail in the coffin. If your server still supports SSL 3.0, it is critically vulnerable.
• TLS 1.0: Deprecated by RFC 8996 in March 2021. Vulnerable to BEAST and other attacks. PCI DSS has required disabling TLS 1.0 since June 2018.
• TLS 1.1: Also deprecated by RFC 8996. No known practical attacks, but all major browsers have removed support.
• TLS 1.2: Still secure when configured with strong cipher suites. Will remain supported for years.
• TLS 1.3: The current standard. Faster handshake (1-RTT vs 2-RTT), no legacy cipher suites, forward secrecy by default. There is no reason not to enable it.

Check which TLS versions your server supports

# Test specific TLS versions
openssl s_client -connect example.com:443 -tls1   # Should FAIL
openssl s_client -connect example.com:443 -tls1_1  # Should FAIL
openssl s_client -connect example.com:443 -tls1_2  # Should SUCCEED
openssl s_client -connect example.com:443 -tls1_3  # Should SUCCEED

# Using nmap for a comprehensive scan
nmap --script ssl-enum-ciphers -p 443 example.com

Nginx configuration for TLS 1.2 and 1.3 only

# /etc/nginx/conf.d/ssl.conf
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;  # Let client choose (TLS 1.3 handles this well)
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

For a deeper comparison of TLS versions, read our guide on TLS 1.3 vs 1.2.

3. Cipher Suites

A cipher suite defines the algorithms used for key exchange, bulk encryption, and message authentication. Even with TLS 1.2, a weak cipher suite can undermine the entire connection.

Cipher suites to disable immediately

• RC4: Biases in the keystream allow plaintext recovery. Prohibited by RFC 7465.
• 3DES (DES-CBC3-SHA): Sweet32 attack (2016) exploits the 64-bit block size. Deprecated.
• CBC mode ciphers without AEAD: Vulnerable to padding oracle attacks (Lucky13). Use GCM or ChaCha20-Poly1305 instead.
• NULL ciphers: No encryption at all. Should never be enabled.
• Export ciphers: Intentionally weak (40-bit or 56-bit keys). The FREAK and Logjam attacks exploit these.
• Static RSA key exchange: No forward secrecy. If the server's private key is ever compromised, all past traffic can be decrypted. Use ECDHE instead.

Recommended cipher suites for TLS 1.2

# Ordered by preference
ECDHE-ECDSA-AES128-GCM-SHA256    # Best: ECDSA + AES-128-GCM
ECDHE-RSA-AES128-GCM-SHA256      # RSA fallback
ECDHE-ECDSA-AES256-GCM-SHA384    # AES-256 variant
ECDHE-RSA-AES256-GCM-SHA384      # RSA + AES-256
ECDHE-ECDSA-CHACHA20-POLY1305    # Great for mobile (no AES-NI)
ECDHE-RSA-CHACHA20-POLY1305      # RSA + ChaCha20

TLS 1.3 simplifies this entirely. It only supports five cipher suites, all of which use AEAD encryption and forward secrecy. You cannot misconfigure TLS 1.3 cipher suites because there are no bad options.

4. Certificate Chain Validation

An SSL certificate does not stand alone. It is part of a chain of trust that goes from your server certificate, through one or more intermediate certificates, up to a trusted root certificate authority (CA). If the chain is broken, browsers cannot verify the certificate.

Common chain issues

• Missing intermediate certificate: The most common issue. Desktop browsers may cache intermediates and work fine, but mobile browsers and API clients will fail with "unable to verify" errors.
• Wrong order: The chain must be: server cert first, then intermediates, then (optionally) root. Reversed order causes failures.
• Expired intermediate: Even if your server certificate is valid, an expired intermediate breaks the chain.
• Cross-signed certificates: Some CAs have certificates signed by multiple roots. Make sure you are including the correct chain for your intended root.

# Verify the full certificate chain
openssl s_client -connect example.com:443 -servername example.com -showcerts

# Check chain with verification
openssl s_client -connect example.com:443 -servername example.com -verify 5
# Look for: "Verify return code: 0 (ok)"

Use our Certificate Decoder to inspect any certificate in your chain and verify its details.

5. HSTS (HTTP Strict Transport Security)

HSTS tells browsers to always use HTTPS for your domain, even if the user types http:// in the address bar. Without HSTS, a man-in-the-middle attacker can intercept the initial HTTP request before the redirect to HTTPS and serve a malicious page. This is called an SSL stripping attack.

# HSTS header
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# max-age=31536000  = Remember for 1 year
# includeSubDomains = Apply to ALL subdomains (be careful!)
# preload           = Eligible for browser preload list

HSTS deployment checklist

1. Start with a short max-age (e.g., 300 seconds / 5 minutes) to test. If something breaks, users are only locked out for 5 minutes.
2. Verify ALL subdomains use HTTPS before adding includeSubDomains. If any subdomain only has HTTP, it will become completely inaccessible.
3. Gradually increase max-age to 1 week, 1 month, then 1 year.
4. Submit to the HSTS preload list at hstspreload.org once stable. This hardcodes HSTS into browsers, protecting even the first visit.

Learn more about security headers in our Website Security Headers Guide and build a complete header policy with our CSP Builder.

6. Certificate Transparency (CT) Logs

Certificate Transparency is a system where CAs must publicly log every certificate they issue. This means you can monitor CT logs to detect unauthorized certificates issued for your domain — a sign of compromise or a rogue CA.

• Monitor your domains in CT logs. Services like crt.sh let you search for all certificates issued for a domain. If you see a certificate you did not request, investigate immediately.
• Expect CT for all public certificates. Since April 2018, Chrome requires all new certificates to be logged in CT. Certificates without CT are rejected.
• Use CT for subdomain discovery. CT logs reveal all subdomains that have certificates, which is useful for security auditing (and for attackers). Our Exposure Checker uses CT logs to enumerate your subdomains automatically.

# Search CT logs for certificates issued to your domain
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq -r '.[].name_value' | sort -u

# This reveals ALL subdomains that have ever had a certificate issued

7. OCSP Stapling

When a browser receives your certificate, it needs to check whether the certificate has been revoked. There are two methods: CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol). Both have privacy and performance problems because the browser contacts the CA for every connection.

OCSP Stapling solves this. Your server periodically fetches the OCSP response from the CA and "staples" it to the TLS handshake. The browser gets the revocation status without contacting the CA, which is faster and more private.

# Nginx OCSP stapling configuration
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

# Test OCSP stapling
openssl s_client -connect example.com:443 -servername example.com -status
# Look for: "OCSP Response Status: successful"

8. Key Size and Algorithm

Your certificate's private key must be strong enough to resist brute force attacks for its entire validity period.

• RSA 2048-bit: The minimum acceptable key size. Good through at least 2030. RSA 4096-bit provides extra margin but is slower.
• ECDSA P-256 (secp256r1): Equivalent security to RSA 3072-bit but with much smaller keys and faster handshakes. Recommended for new deployments.
• ECDSA P-384: Higher security margin, slightly slower. Used by some government and financial institutions.
• RSA 1024-bit: Completely broken. If you still have a 1024-bit key, replace it immediately.

# Check key size and algorithm of your certificate
openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -text | grep "Public-Key"

# Output examples:
# RSA Public-Key: (2048 bit)
# EC Public-Key: (256 bit)    <-- ECDSA P-256

9. CAA DNS Records

A CAA (Certificate Authority Authorization) DNS record specifies which CAs are authorized to issue certificates for your domain. If an attacker tries to get a certificate from an unauthorized CA, the CA must refuse.

# Add CAA records to your DNS
example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

# Check existing CAA records
dig example.com CAA +short

Use our DNS Lookup tool to check your CAA records. Read more about DNS security in our DNS Record Types Explained guide.

10. Mixed Content

Mixed content occurs when an HTTPS page loads resources (images, scripts, stylesheets) over HTTP. Browsers block mixed active content (scripts, iframes) and warn about mixed passive content (images). This degrades the security of your HTTPS page.

• Use Content-Security-Policy: upgrade-insecure-requests to automatically upgrade HTTP requests to HTTPS.
• Search your codebase for hardcoded http:// URLs. Replace them with protocol-relative URLs (//) or absolute HTTPS URLs.
• Check third-party resources. CDN libraries, analytics scripts, and embedded content must all use HTTPS.

The Complete SSL Checklist

Here is your actionable checklist. Test each item on every domain and subdomain you manage:

1. Certificate is valid and not expired — automate renewal, monitor with alerts
2. Only TLS 1.2 and 1.3 enabled — disable SSL 2.0/3.0, TLS 1.0/1.1
3. Strong cipher suites only — AEAD ciphers (AES-GCM, ChaCha20), no RC4/3DES/CBC
4. Complete certificate chain — include all intermediates, correct order
5. HSTS enabled with long max-age — includeSubDomains, consider preload
6. Certificate Transparency logging active — monitor CT logs for unauthorized certs
7. OCSP Stapling enabled — verify with openssl s_client -status
8. Strong key (RSA 2048+ or ECDSA P-256+) — check with openssl
9. CAA DNS records set — restrict which CAs can issue for your domain
10. No mixed content — all resources loaded over HTTPS

Frequently Asked Questions

Is a free Let's Encrypt certificate as secure as a paid certificate?

Yes, from a cryptographic perspective. The encryption strength of a Let's Encrypt certificate is identical to a $500 EV certificate. Both use the same TLS protocols and cipher suites. The difference is in identity validation: EV certificates verify the legal entity behind the domain (company name, address), while DV certificates (including Let's Encrypt) only verify domain control. For most websites, DV is sufficient. The browser no longer shows the company name in the address bar for EV certificates, which eliminated their main visual advantage.

How often should I rotate my SSL certificate's private key?

Rotate your private key at least once a year, or immediately if you suspect compromise. With Let's Encrypt's 90-day certificates, you can generate a new key with every renewal by using certbot renew --force-renewal (though certbot reuses keys by default). Some organizations rotate keys quarterly as a best practice. The important thing is to have the rotation automated so it is not a manual burden.

My SSL Labs score is A+. Am I secure?

An A+ score means your TLS configuration is excellent, but TLS is only one layer of security. An A+ score does not protect against SQL injection, XSS, exposed API keys, weak passwords, or any application-layer vulnerability. Think of SSL as the lock on the front door — essential, but useless if the windows are open. Run our Exposure Checker to test your full security posture beyond just SSL.

Does TLS 1.3 make all older security concerns irrelevant?

TLS 1.3 eliminates many historical TLS vulnerabilities by removing all insecure cipher suites, but it does not help if your certificate is expired, your chain is incomplete, or you lack HSTS. TLS 1.3 secures the transport layer better than any previous version, but certificate management and header configuration are still your responsibility.

The Bottom Line

SSL is not "install and forget." A certificate that was perfectly configured six months ago may now be using deprecated protocols, approaching expiry, or missing security headers that have become standard. Treat SSL configuration as an ongoing process: automate renewal, monitor CT logs, test your configuration regularly, and follow this checklist with every deployment.

Related tools and articles: SSL Checker, Certificate Decoder, Exposure Checker, DNS Lookup, SSL/TLS Certificates Explained, TLS 1.3 vs 1.2, Security Headers Guide, and 70+ more free tools.