How to check an SSL certificate
Type the domain and press Check SSL. Our server opens a secure connection to the site on port 443 the way a browser does, reads the certificate the server presents and checks it against the list of certificate authorities that browsers trust. At the same time it requests http:// and https:// versions of the home page to see where they lead and which security headers come back.
The report starts with a verdict and the days left until expiry, then lists the certificate details, the chain of certificates the server sent, the HTTPS checks and anything worth fixing, from the most serious down. Check every name your site answers on: example.com and www.example.com can have different certificates.
What the results mean
| Field | What it tells you | What good looks like |
|---|---|---|
| Valid until | The last day the certificate works | Renewed automatically, well before the date |
| Trusted by browsers | Whether the chain leads to a root that browsers accept | Yes |
| Name matches | Whether the address you entered is one of the certificate's names | Yes, for every name the site uses |
| Issued by | The certificate authority that signed it | A public CA such as Let's Encrypt, Google Trust Services, Sectigo or DigiCert |
| Protocol | The TLS version used for this connection | TLS 1.3 or TLS 1.2 |
| Key | The type and size of the certificate's key | ECDSA 256 bits, or RSA 2048 bits or more |
| HTTP to HTTPS | Whether http:// sends visitors to the secure address | A permanent redirect to https:// |
| HSTS | Whether browsers are told to use HTTPS only | Present, with a max-age of six months or more once HTTPS is stable |
Expired, untrusted or mismatched: common errors and fixes
Expired. Most certificates today are renewed by software on the server or by the host. When one expires, the renewal job stopped: a changed DNS record, a firewall rule or a moved site can block the domain validation it needs. Renew by hand to get the site back, then fix the automation so it does not happen again.
Not trusted. Either the certificate is self-signed, or the server sends its own certificate without the intermediate certificate that links it to a trusted root. Desktop browsers sometimes fill the gap from their cache, so the site looks fine to you while phones, apps and other servers fail. Install the full chain file your certificate authority provides.
Name mismatch. The certificate does not list the address that was visited. The classic case is a certificate for example.com on a server that also answers www.example.com. Reissue it with both names. A redirect alone does not fix it, because the browser checks the certificate before it ever sees the redirect.
Old protocol or weak key. Browsers dropped TLS 1.0 and 1.1 in 2020, and certificate authorities no longer issue RSA keys shorter than 2048 bits or SHA-1 signatures. Seeing any of these means the server software or its configuration is years out of date.
HTTPS redirects and HSTS
A valid certificate does not help visitors who arrive on http://. The server should answer every plain HTTP request with a permanent redirect (301 or 308) to the same page on https://. The checker follows that redirect and shows each step, so you can spot a missing redirect or an extra hop. For the full chain of any URL, use the redirect checker.
HSTS (HTTP Strict Transport Security) closes the remaining gap. Once a browser has seen the Strict-Transport-Security header, it switches to HTTPS on its own for as long as max-age says, before any request leaves the device. Start with a short max-age, raise it to a year once every page and subdomain works over HTTPS, and add includeSubDomains and preload only if you plan to submit the domain to the browsers' preload list, which is hard to undo.
Certificate problems often start in DNS: a renewal fails because the domain points somewhere else, or a CAA record does not allow your certificate authority. The DNS checker shows the A, AAAA and CAA records that decide both.
Methodology and limits
- How the certificate is read
- A checker on our own web server opens a TLS connection to the domain on port 443 (or 8443), sends the domain name (SNI) as a browser does, and reads the certificate and the chain the server presents. Trust is checked against a standard bundle of public root certificates, and the name is checked against the certificate's subject alternative names.
- Days left
- Counted from the moment of the check to the certificate's end date, in whole days, in UTC.
- Protocol and cipher
- What our checker and the server agreed for this one connection. A server may also accept older versions that a modern client never asks for; this check does not scan every protocol and cipher.
- HTTP and HTTPS checks
- A second request, from Cloudflare's network, asks for
http://andhttps://plus the domain, follows up to 6 redirects hop by hop and reads theStrict-Transport-Securityheader of the first HTTPS answer. - What is flagged
- Expired, not yet valid or expiring certificates (red at 14 days or fewer, gold at 30), untrusted or self-signed certificates, a missing intermediate, a name mismatch, TLS 1.1 or older, SHA-1 or MD5 signatures, RSA keys under 2048 bits, no redirect from
http://, and a missing or short HSTS header. - Not covered
- Certificate revocation (OCSP and CRL), Certificate Transparency logs, mixed content inside pages, every protocol and cipher the server accepts, client certificates, and mail or other services on other ports. IP addresses, private names and private networks are refused.
- Daily limit
- 40 checks per day per IP address, reset at midnight UTC.
Sources
Show all 7 sources
- IETF, RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3
- IETF, RFC 8996, Deprecating TLS 1.0 and TLS 1.1
- IETF, RFC 6797, HTTP Strict Transport Security (HSTS)
- IETF, RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- MDN Web Docs, Strict-Transport-Security header
- CA/Browser Forum, Ballot SC-081v3, reducing certificate validity and data reuse periods (April 2025)
- Let's Encrypt, FAQ


