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
Perguntas Frequentes
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.
Subject CN (Common Name) is the legacy single hostname field on a certificate. Subject Alternative Names (SAN) is a modern list of every hostname the certificate is valid for, including wildcard entries. Browsers and most mail clients now ignore the CN entirely and validate the SAN list, so any hostname missing from SAN will fail TLS verification.
Self-signed certificates are unsafe for any public-facing service. They encrypt the connection but provide no proof of identity, so browsers, mobile devices, and corporate mail clients will reject them. Self-signed certificates are only acceptable for development, private internal services where you control every client, or as a stepping stone before issuing a trusted certificate.
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.