SSL Certificate Checker
Inspect a domain's SSL/TLS certificate: subject, issuer, validity dates, days remaining, SAN list, wildcard support, self-signed detection.
- Free · no sign-up
- Instant results
- Privacy-friendly
Other SEO Tools
What the check tells you
Enter a hostname and the tool opens a TLS connection and reports what the server presents: who issued the certificate, which hostnames it covers, when it expires, whether it is a wildcard, and whether it is self-signed.
This answers the questions that come up when a site starts showing browser warnings. Is the certificate expired, does it actually cover the hostname visitors are typing, and was it issued by an authority browsers trust? Those three account for the overwhelming majority of certificate problems.
Expiry is the failure that will actually happen to you
Certificates expire on a fixed date and browsers refuse them the moment they do — no grace period, no soft warning. A visitor gets a full-page security interstitial they must click through, and most will not. Outages from expired certificates are common, embarrassing, and entirely preventable.
The industry is also shortening lifetimes steadily; the maximum has fallen from years to months and continues to drop, which makes manual renewal increasingly impractical. Automated issuance through ACME — Let's Encrypt and equivalents — with renewal roughly a third of the way before expiry is now the only sensible approach. Set an independent expiry alert too, because the most dangerous failure is an automated renewal that silently stops working.
Name mismatches and the www problem
A certificate is valid only for the names listed inside it, in the Subject Alternative Name field. The single most common oversight is covering example.com but not www.example.com, or the reverse. Visitors reaching the uncovered variant get a warning even though the certificate itself is perfectly valid.
Wildcards are worth understanding precisely: *.example.com covers api.example.com and blog.example.com, but it does not cover the bare example.com, and it does not cover a second level such as a.b.example.com. If you use a wildcard, check that the apex domain is listed explicitly as well.
The chain, and why it works locally but not on mobile
Trust is established through a chain from your certificate up to a root the client already trusts. Your server must send the intermediate certificates that link the two. Omitting them produces one of the most confusing failures in TLS: the site works in your browser, because it happens to have cached the intermediate from another site, while other visitors — particularly on mobile devices and older clients — get an untrusted warning.
That is why an incomplete chain often survives internal testing and only surfaces through customer complaints. If a certificate looks correct but some users report warnings, an incomplete chain is the first thing to check.
What HTTPS means for SEO
HTTPS is a confirmed, if lightweight, ranking signal, and it has been for a decade. The more consequential effects are indirect: browsers mark HTTP pages as not secure, which damages trust and conversion, and referral data from HTTPS sites is stripped when it arrives at an HTTP site, distorting your analytics.
Getting HTTPS right also means serving one canonical version. Redirect HTTP to HTTPS in a single hop, pick either www or the apex and redirect the other to it, and make sure internal links and canonical tags all point at that chosen version. Mixed HTTP and HTTPS URLs of the same page split signals between duplicates and can leave the wrong one indexed.