SSL Checker
Enter a domain and see the TLS certificate it actually serves: how many days are left before it expires, whether the chain verifies against the public root store, whether the name matches, which hostnames the SANs cover, and which TLS versions the server still accepts. Each certificate in the chain can be opened in the certificate decoder or exported as PEM. It is free and needs no sign-up.
- Live handshake against the host — no PEM to paste, just a domain name
- Days-until-expiry countdown, with the exact not-before and not-after timestamps
- Separate verdicts for chain trust, hostname match, expiry, and a chain the server sent in full
- TLS 1.0 to 1.3 support matrix with the cipher negotiated for each version
- Full chain view with SANs, key size, fingerprints, and one-click export as PEM or JSON
The hostname sent during the handshake. Leave it empty to use the host above; set it when you connect to one IP but want the certificate for a particular name.
Overview
One check answers the questions that come up when a certificate misbehaves: when it expires, whether it is trusted, which names it covers, and what the server negotiates.
- 01
Expiry countdown
The days remaining are shown as a number you can act on, colour-coded as the deadline approaches, alongside the exact validity window in UTC.
- 02
Each verdict on its own line
Trust, hostname match, validity period, a chain served in full, and deprecated protocol versions are reported one by one, so a name mismatch never hides an untrusted chain.
- 03
Every name the certificate covers
The full list of subject alternative names, including wildcards, so you can confirm a subdomain is covered before you point it at the server.
- 04
TLS version support
TLS 1.0, 1.1, 1.2, and 1.3 are each probed separately, with the cipher suite negotiated for the versions the server accepts.
- 05
The chain as the server sends it
Leaf, intermediates, and any root the server includes, each with its issuer, key, usages, fingerprints, and OCSP and CRL endpoints.
- 06
Export and hand off
Download the chain as fullchain.pem or the whole result as JSON, or open any single certificate in the certificate decoder for a field-by-field read.
How to use
Check a certificate the way a browser sees it: type the host, read the verdicts, then dig into the chain.
- 01
Type a domain — or paste a full URL, the scheme and path are ignored — and press Check.
- 02
Set a port if the service does not listen on 443, and an SNI hostname if you are connecting straight to an IP.
- 03
Read the countdown and the checks: trust, hostname, expiry, whether the chain was served in full, and any deprecated protocol still accepted.
- 04
Scan the TLS version matrix for TLS 1.0 or 1.1 still being accepted, and note the negotiated cipher.
- 05
Open any certificate in the chain for its SANs and fingerprints, then export the chain as PEM or the result as JSON.
Details
Certificates fail in a handful of familiar ways, and each one has its own line in the result rather than a single pass or fail.
- The check runs a real handshake from the DevKitLab service, so it reports the endpoint that service reaches rather than anything cached in your browser
- Trust and hostname verification are reported separately, because a certificate can be perfectly valid and still be the wrong one for the name
- An incomplete chain is called out even when your browser papers over it via the AIA link, since stricter clients and older devices will not
- The expiry countdown goes negative for a certificate that has already lapsed, so the size of the problem is obvious
- Services that begin with TLS on the port are supported — implicit-TLS mail ports, LDAPS, and compatible services on non-standard ports
- Setting SNI separately from the host lets you test a specific server behind a load balancer or an anycast address
Use cases
Certificate lifetimes keep getting shorter — 90 days is typical now — and most visits to a page like this happen right after something broke.
-
Confirm renewal actually took effect
After a certificate renews, check the host itself: the countdown proves the new certificate is being served rather than sitting unused on disk.
-
Track down a browser trust warning
Separate the three usual causes — expired, untrusted chain, wrong hostname — instead of guessing from the browser error page.
-
Find a missing intermediate
A site that works in your browser but fails in curl, Java, or a mobile app is usually a chain the server does not serve in full.
-
Verify a subdomain is covered
Read the SAN list to see whether the wildcard or the explicit name you are about to deploy is actually in the certificate.
-
Check a service on a non-standard port
Mail on 465, IMAPS on 993, LDAPS on 636, or another service that begins with TLS on its own port — set the port and inspect what it presents.
-
Audit protocol support before a compliance review
See whether the server still accepts TLS 1.0 or 1.1 and which cipher each version negotiates, then take the result to the ticket.
See also
When you already have the certificate as a PEM file and want every extension parsed field by field, use the Certificate Decoder. If the host does not resolve at all, or you need to confirm the CAA record that controls who may issue certificates for the domain, start with DNS Lookup. And to compare a certificate fingerprint against a value you were given, compute digests locally with the Hash Generator.
Best practices
A certificate check is a snapshot of one endpoint at one moment. These habits keep the result meaningful.
- Check the hostname your users type, including the www and apex variants — they are often served by different configurations.
- Renew well before the countdown reaches single digits; automated renewal that silently failed is the most common outage cause.
- Treat an incomplete chain as a real bug even if browsers cope, because API clients, older Android devices, and language runtimes often do not.
- Behind a load balancer, check each origin by IP with SNI set, since one node can be left on an old certificate.
- Turn off TLS 1.0 and 1.1 once you know nothing depends on them; both are deprecated and are commonly flagged in audits.
- Save the JSON export with a ticket when you are handing an incident over, so the exact state at that moment is recorded.
Limitations
The tool performs an outbound TLS handshake and reports what the server presented. That is deliberately narrower than a full security rating.
- Revocation is not checked. OCSP responder and CRL endpoints are listed from the certificate, but they are not queried, so a revoked certificate can still look valid here.
- Only publicly reachable hosts can be checked. Private, loopback, link-local, and reserved addresses are refused, so an internal server needs a local tool such as openssl s_client.
- The result reflects the endpoint our server reached. Anycast and geo-routed setups may serve a different certificate to other regions.
- There is no letter grade. Cipher order, key exchange strength, and known protocol vulnerabilities are outside what this check reports.
- Certificate Transparency logs, HSTS policy, and mixed-content problems are separate concerns and are not inspected here.
- Checks run through the DevKitLab service, which makes the connection on your behalf; the target host sees our address, not yours.
FAQ
Common questions about expiry, trust errors, hostname mismatches, ports, and what the check does not cover.
How do I check the SSL certificate of a website?
Type the domain — example.com, or a full URL, the scheme and path are ignored — and press Check. The tool opens a TLS connection to the host and reports the certificate it serves: days until expiry, whether the chain is trusted, whether the name matches, the SANs, and which TLS versions the server accepts.
When does my SSL certificate expire?
The countdown at the top of the result is the number of days left on the certificate currently being served, with the exact not-before and not-after timestamps in UTC beside it. A negative number means it already expired that many days ago.
What does “certificate chain is not trusted” mean?
It means the chain the server presented could not be verified up to a certificate in the public root store. The usual causes are a self-signed certificate, a private or internal CA that public clients do not know, a missing intermediate, or a certificate that has expired. The reason returned by the verifier is shown next to the failed check.
Why does the certificate not match the hostname?
A certificate is only valid for the names in its subject alternative names, and a wildcard like *.example.com covers one label — it matches api.example.com but not example.com or a.b.example.com. The check reports trust and hostname separately, so you can see a chain that is perfectly valid but issued for a different name.
My site works in Chrome but fails in curl or my app. Why?
That pattern almost always means the server is not sending the intermediate certificates. Browsers can fetch a missing issuer through the AIA link in the certificate and quietly recover; curl, Java, Go, and older mobile devices usually do not. The “chain served in full” check flags exactly this.
Can I check a certificate on a port other than 443?
Yes. Set the port field, or paste the host with the port attached as example.com:8443. It works for services that begin with TLS on that port, such as mail submission on 465 or LDAPS on 636. Protocols that upgrade after a plaintext greeting, such as STARTTLS on port 587, and services that need a protocol-specific TLS negotiation are not supported.
What is SNI and when do I need to set it?
SNI is the hostname sent during the handshake so a server hosting many sites knows which certificate to present. It defaults to the host you entered. Set it explicitly when you connect straight to an IP address but want the certificate for a particular name — useful for testing one node behind a load balancer.
Does this check whether a certificate has been revoked?
No. The OCSP responder and CRL endpoints published in the certificate are listed, and the result shows whether the server stapled an OCSP response during the handshake, but those endpoints are not queried. A revoked certificate that is still inside its validity window will look valid here.
Should I still support TLS 1.0 and 1.1?
Generally no. Major browsers dropped both in 2020, and audits routinely flag them. The version matrix probes all four versions separately, so you can confirm what the server actually accepts rather than what the configuration file suggests — and any deprecated version still accepted is called out as a warning.
Can I check localhost or a server on my internal network?
No. The check runs from our server, so it can only reach hosts on the public internet, and private, loopback, link-local, and reserved addresses are refused outright. For an internal host, run openssl s_client -connect host:port -servername host locally and paste the PEM into the certificate decoder.
Related tools
Read a certificate you already have, or work back down the stack to the DNS records and the address behind the name.