How to Check an SSL Certificate: A Developer's Guide to TLS Verification

An expired or misconfigured SSL certificate does not just show a browser warning. It breaks trust, kills conversions, and can take down API integrations that enforce certificate validation. I've been paged at 3 AM over a cert that nobody remembered to renew. Monitoring your certificates proactively is boring work, but it saves you from exactly that kind of incident.

What SSL/TLS Certificates Actually Do

An SSL/TLS certificate does two things. First, it verifies identity: the certificate proves that the server you are connecting to is legitimately operated by whoever owns the domain, because a Certificate Authority (CA) has vouched for it by signing the cert. Second, it sets up encryption. During the TLS handshake, the certificate's public key establishes an encrypted connection, so all data exchanged afterward is protected from eavesdropping and tampering.

Without a valid certificate, browsers show a security warning and most users leave. Search engines penalize your site too. For APIs, invalid certificates cause connection failures that cascade through your service's dependency chain.

Anatomy of an SSL Certificate

When you inspect a certificate (click the padlock icon in your browser), you'll see several fields. The Common Name (CN) and Subject Alternative Names (SANs) list the domain(s) the certificate covers; a wildcard certificate for *.example.com covers all subdomains. The Issuer is the Certificate Authority that signed it (Let's Encrypt, DigiCert, Sectigo, etc.). The Valid From and Valid To dates define the certificate's validity window, and outside that window, the certificate gets rejected. You'll also find a Serial Number used for revocation checking, a Signature Algorithm (typically RSA with SHA-256 or ECDSA; older SHA-1 certificates are no longer trusted), and the Public Key itself (RSA 2048-bit or ECDSA P-256 are current standards).

How to Check a Certificate from the Command Line

The openssl command is your go-to tool for certificate inspection.

# Connect and display the certificate
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -text

# Check expiration date only
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

# Check which domains the certificate covers
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

The -servername flag matters for servers that host multiple domains (SNI). Without it, you might get the wrong certificate back.

For a quick check using curl:

# Show certificate details during a request
curl -vI https://example.com 2>&1 | grep -A 6 "Server certificate"

Common Certificate Errors and How to Fix Them

Certificate Expired

This is the one you'll hit most often. The certificate's "Not After" date has passed. Renew the certificate. If you use Let's Encrypt with certbot, check that the cron job or systemd timer for certbot renew is actually running. Test with certbot renew --dry-run.

Certificate Name Mismatch

The domain in the browser does not match any of the certificate's SANs. This happens when you access a site via a subdomain not covered by the cert, or when you set up a new domain and forgot to issue a new one. Issue a certificate that includes all required domains, or use a wildcard certificate.

Intermediate Certificate Missing

Browsers need the full certificate chain: your server's certificate plus the intermediate certificate(s) linking it to the root CA. If the intermediate is missing, some browsers work fine because they have the intermediate cached, while others fail. Mobile browsers and API clients are the usual victims. Configure your web server to serve the full chain. Most CAs provide a "full chain" or "bundle" file for this.

Self-Signed Certificate

The certificate was not signed by a trusted CA. Fine for development, unacceptable in production. Use a certificate from a trusted CA. Let's Encrypt is free and automated.

Mixed Content

Your page loads over HTTPS but includes resources (images, scripts, stylesheets) over HTTP. Browsers block or warn about these requests. Make sure all resource URLs use HTTPS or protocol-relative URLs.

Automated Certificate Monitoring

Checking manually does not scale. You'll want to set up ongoing monitoring, and there are a few solid ways to do it. If you're on Let's Encrypt, certbot handles auto-renewal through a cron job or systemd timer. Most uptime monitoring services like UptimeRobot, Pingdom, or Better Uptime can alert you when a certificate is approaching expiry. You can also write a simple cron job that runs openssl s_client, checks the expiry date against a threshold like 14 days, and fires alerts via email, Slack, or PagerDuty. If you're worried about unauthorized certificate issuance, keep an eye on Certificate Transparency Logs for your domain.

You can also monitor your site's overall health with our Website Status Checker and verify DNS configuration with the DNS Lookup tool.

SSL/TLS Best Practices for 2026

Use TLS 1.3. It gives you faster handshakes and stronger security. Disable TLS 1.0 and 1.1 entirely; TLS 1.2 is acceptable as a fallback. Enable HSTS by adding the Strict-Transport-Security header, which tells browsers to always use HTTPS and prevents downgrade attacks. Consider ECDSA certificates over RSA since they use smaller keys and produce faster handshakes. A P-256 ECDSA certificate matches the security of RSA-3072. Set up OCSP stapling so your server includes the certificate's revocation status in the TLS handshake, removing the need for clients to contact the CA separately. And finally, monitor certificate expiry with alerts at 30, 14, and 7 days before it hits. Automate renewal wherever possible.