SSL / TLS checker
Inspect a site's certificate, chain, protocols and expiry date.
Have feedback or an idea for this tool?
What is an SSL/TLS certificate?
An SSL/TLS certificate lets a website serve traffic over HTTPS and proves its identity to the browsers that connect to it. This checker opens a read-only TLS connection to a domain on port 443, reads the certificate the server presents, and reports the issuer, the hostnames it covers, the valid-from and valid-to dates, the days left before it expires, and the chain of intermediate certificates up to a trusted root. Use it to spot a certificate that is about to expire, to confirm that a newly installed certificate is being served correctly, or to check that the chain is complete so every client trusts it. Enter a domain such as example.com, with or without the https prefix, and the result shows whether the certificate is valid today and when it needs renewing.
Key facts
- An SSL/TLS certificate binds a public key to a set of hostnames and proves that a Certificate Authority verified control of those hostnames before signing it.
- The certificate chain flows from a leaf certificate up through one or more intermediate CA certificates to a self-signed root that lives in the client's trust store.
- A server must send its leaf certificate plus every intermediate but not the root, and a missing intermediate is the most common misconfiguration - it passes in Chrome yet fails in curl, Java, Python requests and mobile apps.
- Modern clients match the visited hostname only against the Subject Alternative Name (SAN) extension and ignore the legacy Common Name, so a hostname missing from the SAN triggers NET::ERR_CERT_COMMON_NAME_INVALID.
- Let's Encrypt and most modern free CAs issue 90-day certificates, and TLS 1.3 and 1.2 should be enabled while TLS 1.0 and 1.1 are deprecated and should be disabled.
What an SSL/TLS certificate actually proves
An SSL/TLS certificate binds a public key to a set of hostnames and proves that a Certificate Authority (CA) verified control of those hostnames before signing. It does two jobs at once: it lets the client encrypt the session with the server's public key, and it authenticates that you are talking to the real owner of the domain and not a machine-in-the-middle.
The certificate does not prove the business behind the site is trustworthy, only that whoever holds the matching private key controlled the domain at issuance time. Domain Validated (DV) certs, which Let's Encrypt and most free issuers hand out, confirm domain control only. Organisation Validated (OV) and Extended Validation (EV) certs add vetted company details to the Subject field but are otherwise the same TLS underneath.
This checker reads the live certificate served on the TLS handshake, so it reflects exactly what browsers and API clients see, not what is sitting in a file on disk.
The chain of trust: leaf, intermediate and root
Trust flows top-down. A root CA certificate lives in the browser or OS trust store and is self-signed. Roots almost never sign server certificates directly; instead they sign one or more intermediate CA certificates, and those intermediates sign your leaf (end-entity) certificate. A client trusts your site only if it can build an unbroken path from your leaf up to a root it already trusts.
Your server is responsible for sending the leaf plus every intermediate in the chain. It must not send the root, since the client already has it. If an intermediate is missing, the client cannot complete the path and rejects the connection, even though the leaf itself is perfectly valid. This is the single most common misconfiguration and the reason a cert can pass in Chrome (which sometimes caches or fetches intermediates) yet fail in curl, Java, Python requests or a mobile app.
The checker walks the chain it receives, shows each certificate's issuer and subject, and flags an incomplete chain so you can fix the fullchain file your server sends.
Reading issuer, subject, validity and SAN
Issuer is the CA that signed the certificate; Subject is who it was issued to. On modern certificates the Subject Common Name (CN) is legacy and effectively ignored - browsers match the hostname only against the Subject Alternative Name (SAN) extension. If the hostname you visit is not listed in the SAN, you get NET::ERR_CERT_COMMON_NAME_INVALID or a name-mismatch error, regardless of what the CN says.
Validity is the notBefore and notAfter window in UTC. A certificate is untrusted before notBefore (clock-skew problems on the server look like this) and after notAfter (expired). Wildcards such as *.example.com cover one label only, so they match api.example.com but not deep.api.example.com and never the bare example.com unless that is listed separately.
You can read the same fields from the command line with: openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -issuer -subject -dates -ext subjectAltName. The -servername flag is required because virtually all hosts use SNI to serve the right certificate per hostname on a shared IP.
Expiry, TLS versions and staying green
Let's Encrypt and most modern free CAs issue 90-day certificates by design, on the assumption that renewal is automated. Certbot, acme.sh, Caddy and most panels renew at around the 30-day-remaining mark. The failure mode to watch is a renewal cron that silently breaks - the cert quietly ages out and the site goes dark. Monitor days-to-expiry rather than trusting that automation is running, and alert well before zero.
On the protocol side, prefer TLS 1.3 and keep TLS 1.2 for older clients; TLS 1.0 and 1.1 are deprecated and should be disabled. TLS 1.3 drops the round trip and removes weak cipher suites, so it is both faster and safer. The certificate itself is version-agnostic - the same cert works over 1.2 and 1.3 - so a protocol problem is a server-config problem, not a certificate problem.
The industry is moving toward much shorter lifetimes (45 days from 2029 under the CA/Browser Forum plan), which makes automated renewal and expiry monitoring non-optional rather than nice-to-have.
Glossary
- Certificate chain
- The ordered path of certificates a client follows to establish trust, running from the leaf up through one or more intermediate CA certificates to a trusted root. A client accepts the connection only if it can build an unbroken path from the leaf to a root it already trusts.
- Leaf (end-entity) certificate
- The certificate issued to the actual server, binding its public key to the hostnames it serves. It is signed by an intermediate CA rather than directly by a root, and is the certificate presented first in the TLS handshake.
- Intermediate CA certificate
- A certificate signed by a root CA that in turn signs leaf certificates, forming the middle of the chain of trust. The server must send every intermediate along with the leaf, since a missing intermediate is the most common cause of a chain that passes in Chrome but fails in curl, Java or mobile apps.
- Root CA certificate
- A self-signed certificate held in the browser or operating system trust store that anchors the chain of trust. Roots almost never sign server certificates directly and are not sent by the server, because the client already holds them.
- Subject Alternative Name (SAN)
- The certificate extension listing every hostname the certificate is valid for. Modern clients match the visited hostname only against the SAN and ignore the legacy Common Name, so a hostname absent from the SAN triggers a name-mismatch error such as NET::ERR_CERT_COMMON_NAME_INVALID.
- TLS handshake
- The negotiation at the start of a connection where the server presents its certificate and the two sides agree on keys and a protocol version to encrypt the session. TLS 1.3 and 1.2 are the versions to offer, while TLS 1.0 and 1.1 are deprecated and should be disabled.
Questions, answered.
Why does my certificate work in Chrome but fail with curl or a mobile app?+
Almost always an incomplete chain. Browsers can cache or fetch missing intermediate certificates using the AIA extension, but curl, Java, Python requests and mobile apps do not. Fix it by serving the full chain (leaf plus all intermediates, in order) - point your server at the fullchain.pem file rather than the bare certificate.
What does NET::ERR_CERT_COMMON_NAME_INVALID mean?+
The hostname you visited is not listed in the certificate's Subject Alternative Name (SAN) extension. Modern clients ignore the legacy Common Name and match only against the SAN, so the fix is to reissue the certificate with every hostname you serve included in the SAN, or use a wildcard that covers them.
Why is my Let's Encrypt certificate expired when renewal was set up?+
The renewal job silently stopped. Common causes: the certbot systemd timer or cron was disabled, a pre/post hook fails, port 80 got firewalled so the HTTP-01 challenge cannot validate, or the DNS changed. Run your renew command with --dry-run to reproduce the failure, and monitor days-to-expiry so a broken renewal alerts you before the cert lapses rather than after.
Is a self-signed certificate a problem?+
For anything public-facing, yes - a self-signed certificate is not signed by a trusted CA, so browsers and clients reject it with an untrusted-issuer error. Self-signed certs are fine for local development or internal services where you control every client and can pin or install the cert, but for a real domain use a CA-issued certificate such as a free Let's Encrypt one.
How do I check a certificate's expiry from the command line?+
Run: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates. This prints notBefore and notAfter. The -servername flag sends SNI so you get the right certificate on a shared IP. This checker does the same handshake and shows days remaining directly.
What is the difference between the certificate and the TLS version?+
The certificate proves identity and carries the public key; the TLS version (1.2, 1.3) is the protocol used to negotiate the encrypted session. The same certificate works across TLS versions, so a handshake failure or a weak-protocol warning is a server configuration issue, not a certificate one. Aim to offer TLS 1.3 and 1.2 only, and disable the deprecated 1.0 and 1.1.
Does a wildcard certificate cover subdomains of subdomains?+
No. A wildcard like *.example.com covers exactly one label, so it matches api.example.com and www.example.com but not deep.api.example.com, and it does not cover the bare example.com unless that apex name is listed separately in the SAN. For multiple levels you need a certificate that lists each pattern or a multi-domain (SAN) certificate.
How many days before expiry should I renew, and how do I get warned?+
Renew with a comfortable buffer - most automated tools renew at 30 days remaining, and you should alert if a cert drops below roughly 14 days so a failed renewal is caught in time. Rather than trusting the cron is running, monitor days-to-expiry per host. ServerCake can watch your certificates and email you before one lapses.
Cloud that speaks India.
These tools run on ServerCake infrastructure in India. When our cloud opens, you get VMs and managed databases priced in ₹, billed with GST, on India-resident infrastructure. Reserve your spot for early access.
Reserve your spot