How to use the SSL Checker
- Enter a domain such as
example.com, or paste a full URL. The tool uses the hostname from the URL. - Run the check. We connect to the server on port 443 and read the certificate it presents.
- Read the verdict at the top: whether the certificate is trusted and whether it covers the hostname you entered.
- Review the details, especially the expiry date and the number of certificates in the chain.
- If there is an error, read the explanation under the verdict, fix the server configuration and check again after the cache period.
Understanding your results
Trusted. The certificate chains up to a certificate authority that is trusted by default. If it does not, browsers show a security warning and most visitors will leave.
Covers the hostname. Whether the name you entered appears in the certificate. Modern clients match against the Subject Alternative Names only, not the older Common Name field, as set out in RFC 9525. A wildcard such as *.example.com matches exactly one label: it covers www.example.com but not example.com itself and not a.b.example.com.
Issuer. The certificate authority that signed the certificate.
Subject and Subject Alternative Names. The subject identifies who the certificate was issued to. The SAN list shows every hostname the certificate is valid for. If you serve both example.com and www.example.com, both should appear.
Valid from, valid to and days until expiry. The certificate's validity window. Once it passes the "valid to" date, every visitor sees an error. A small number of days remaining means renewal should happen now, or your automated renewal should be checked.
Signature algorithm. How the issuer signed the certificate, for example SHA-256 with RSA or ECDSA with SHA-256. Certificates signed with SHA-1 are no longer trusted by modern browsers.
Key type and size. RSA keys are commonly 2048 bits or larger. ECDSA keys, such as P-256, are smaller but provide comparable security.
Chain served. How many certificates the server sent. A typical correct setup sends the site certificate plus one or more intermediate certificates. If only one certificate is served for a publicly issued certificate, an intermediate is usually missing.
TLS protocol. The version negotiated for our connection. TLS 1.3 and TLS 1.2 are current. TLS 1.0 and 1.1 are deprecated and widely disabled.
Common errors we explain
- Expired. The "valid to" date has passed. Renew the certificate and reload the web server.
- Self-signed. The certificate was signed by its own key rather than a trusted authority. Fine for internal testing, not for a public site.
- Wrong hostname. The name you entered is not in the SAN list. Reissue the certificate with the missing name, or check that the server is presenting the right certificate for this hostname.
- Incomplete chain. The server did not send the intermediate certificates. Some browsers work around this, but other clients fail. Install the full chain your certificate authority provides.
For fixes to each of these, see our guide to SSL certificate errors.
How this tool works
We open a TLS connection to port 443 using SNI, so servers that host many sites return the certificate for the hostname you entered. We then validate the chain the server sends against trusted certificate authorities and check whether the hostname is covered.
If validation fails, we still read the certificate and show its details, together with a plain explanation of what failed. That way you can see, for example, whether a certificate is expired or simply missing an intermediate.
Results are cached for 6 hours. After renewing or replacing a certificate, the old result may be shown until the cache expires.
This is one connection from our server. If your site runs on several servers or behind a CDN, different visitors can reach different machines, and each one can be configured differently. We check port 443 only.
Tips
- Automate certificate renewal and monitor it, rather than relying on a calendar reminder.
- Include every hostname you serve, typically both the root domain and
www, in the certificate. - Always install the full chain file from your certificate authority, not just the site certificate.
- Reload or restart the web server after installing a new certificate; otherwise the old one keeps being served.
- If your domain has CAA records, make sure they allow your certificate authority. You can see them with the DNS Lookup.
- Once HTTPS works, send HTTP traffic to it with a permanent redirect, and confirm it with the Redirect Checker.
Frequently asked questions
Why does my browser show the site as secure when this checker reports an incomplete chain?
Some browsers can fill in a missing intermediate certificate from a cache or by downloading it. Other clients, such as apps, scripts and some devices, do not, so they fail. Serving the full chain fixes the problem for everyone.
Does a wildcard certificate cover the root domain?
No. A wildcard like *.example.com matches one label, so it covers www.example.com or shop.example.com but not example.com. The root name must be listed as a separate SAN.
Why does the result not change after I renewed my certificate?
Results are cached for 6 hours. If the old certificate still shows after that, the web server has probably not been reloaded, or the new certificate was installed on a different server than the one answering requests.
What does "self-signed" mean?
The certificate was signed with its own key instead of by a trusted certificate authority. Browsers cannot verify it, so they show a warning. Public sites should use a certificate from a trusted authority.
Does SSL affect SEO?
Google has said HTTPS is a lightweight ranking signal. The bigger effect is practical: certificate errors show a warning page, and most visitors will not click past it.
How often should I check my certificate?
Check after every renewal or server change, and a few weeks before the expiry date if renewal is not automated. Automated renewal still needs occasional checks, because it can fail silently.