What is an SSL certificate?
An SSL/TLS certificate is a digital document, signed by a trusted Certificate Authority (CA), that binds a public key to one or more hostnames. When a client connects, the server presents the certificate as part of the TLS handshake and the client verifies the CA's signature, the certificate's validity window, and that one of the listed names matches the host it intended to reach.
Despite the legacy name, modern certificates use the TLS protocol (TLS 1.2 and TLS 1.3 today) rather than the deprecated SSL. The X.509 certificate format and PKI chain are defined in RFC 5280, with HTTPS-specific behavior in RFC 2818.
Why check your SSL certificate?
1Prevent surprise expiry
Every browser and modern mail client breaks the moment a certificate lapses — track days remaining proactively
2Confirm hostname coverage
A certificate is only valid for the hostnames in its SAN list — verify every subdomain you serve
3Detect untrusted chains
Self-signed or unknown-CA certificates trigger browser warnings — surface them before users do
4Audit STARTTLS for email
Mailbox providers expect MX endpoints to negotiate TLS cleanly — a broken cert quietly degrades deliverability
How SSL verification works — step by step
A client opens a TLS connection to your domain and sends a ClientHello.
Your server returns its certificate chain: leaf certificate + any intermediate CA certificates.
The client walks the chain up to a trusted root CA installed in its trust store.
It verifies each signature, checks each certificate is within its validity window, and confirms none are revoked.
Finally it checks that the leaf certificate's SAN list contains the hostname the client is trying to reach.
If every step passes, the handshake completes and the session key is exchanged.
Certificate fields at a glance
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -textKey certificate fields
Issuer— Certificate Authority that signed the certSubject CN— legacy primary hostnameSAN— modern list of valid hostnamesNot Before / After— validity windowKey Usage— permitted operations (server auth, etc.)Common SSL failures and fixes
Expired certificate
Renew immediately and set up monitoring — most teams alert at 30 days remaining
Hostname mismatch
The hostname you tested isn't in the SAN — reissue with the missing name or a correct wildcard
Self-signed certificate
Browsers reject these — switch to a free Let's Encrypt cert or your CDN's managed cert
Incomplete chain
If intermediates are missing, some clients can't verify the chain — bundle them with the leaf in your server config
Frequently Asked Questions
An SSL/TLS certificate checker confirms that a domain serves a valid certificate from a trusted Certificate Authority, that the certificate's Subject and Subject Alternative Names cover the hostname you tested, that the certificate is currently within its validity window, and that it is not self-signed. These checks together prove a browser or mail client will trust the connection.
Once a certificate expires, every browser will display a security warning and most modern mail clients will refuse STARTTLS. Letting an SSL certificate lapse breaks both web traffic and authenticated email submission. Monitoring days-remaining gives you a buffer to renew — most teams trigger an alert below 30 days.
Hostname mismatch happens when the certificate's SAN list does not include the exact name you tested. Common causes are testing a www subdomain against an apex-only certificate, missing a wildcard for sub-subdomains, or accidentally serving the wrong virtual host on a shared IP. Reissue the certificate with the correct SAN entries.
Yes, indirectly. Mailbox providers expect MX, SMTP submission, and tracking-domain endpoints to negotiate TLS successfully. A broken or expired certificate forces a downgrade to plaintext or a delivery failure, which lowers your reputation over time. Keeping all email-related domains green-padlocked is part of a healthy authentication posture.
Reissue the certificate through your hosting provider or certificate authority, or enable auto-renewal with a service like Let's Encrypt to prevent future lapses. After installing the new certificate, run an SSL checker to confirm the expiry date and certificate chain are valid.
An expired certificate on your sending infrastructure can break TLS connections and undermine the trust signals receivers look for, which can hurt deliverability. Keeping certificates valid on your mail server and the websites linked in your emails helps protect both your reputation and recipient trust.