Fast, practical, browser-based developer tools
Confirm whether a domain serves a valid, browser-trusted HTTPS certificate, and view issuer and expiry details when they are available from the public Certificate Transparency logs. This tool is useful for certificate monitoring, troubleshooting, security reviews, and website validation workflows.
SSL certificate checks help verify whether a domain is reachable over HTTPS and whether its certificate appears current and usable. This is useful for websites, apps, support diagnostics, and certificate review workflows.
Deep certificate inspection is usually more reliable through a backend service. Browser-based tools may be limited by CORS rules, network restrictions, and endpoint behavior.
For more details about site usage and analytics, read our Privacy Policy.
Enter the domain name you want to inspect, run the SSL check, and review the returned HTTPS and certificate-related information. You can copy the output for support, diagnostics, or documentation workflows.
✅ HTTPS connection to example.com succeeded. The SSL/TLS certificate is currently valid and trusted by browsers. Certificate details (from public Certificate Transparency logs): Issuer: C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 Common name: www.example.org Valid from: 2024-01-30T00:00:00 Valid until: 2025-03-01T23:59:59 (180 day(s) remaining)
A TLS certificate makes exactly one guarantee: at issuance time, whoever requested it demonstrated control of the hostname (typically by answering a challenge on the domain or its DNS). It says nothing about whether the operator is honest or the site is malware-free. The padlock means “the connection is encrypted and you are talking to whoever controls this name” — not “this business is legitimate.” Phishing sites get valid certificates too, because they do control their own lookalike domain. Read a certificate as an anti-eavesdropping and anti-impersonation guarantee for one specific hostname, not as a trust badge.
A certificate is not one file, it is a chain: your server's leaf certificate is signed by an intermediate CA, which is signed (directly or through more intermediates) by a root that clients already trust. A client only trusts the leaf if it can build that whole path up to a trusted root.
The single most common production TLS incident is a server that sends its leaf but
forgets to send the intermediate. Here is why it is so nasty: it often looks
fine in your browser. Browsers cache intermediates they have seen before, and many will fetch
a missing one on the fly using the AIA URL in the certificate. So the site loads
perfectly for you — while curl, Java clients, Android apps, Go services,
and payment webhooks fail with “unable to get local issuer certificate.” The fix
is to serve the full chain (leaf plus intermediates), which is why proper tooling deploys
fullchain.pem rather than the leaf alone.
The browser collapses several distinct failures into one scary page. Knowing which one you have points straight at the fix:
notAfter. Renew it; if you keep hitting this, automate renewal.CN) field is deprecated and ignored by Chrome and others, so a name present only in the CN and not the SAN still fails.
Every publicly trusted certificate is logged to append-only Certificate
Transparency (CT) logs, which browsers require. That has a useful side effect:
anyone can watch CT (through services like crt.sh) to see every certificate
issued for their domains, which surfaces mis-issuance and forgotten subdomains. It also means
you cannot obtain a “secret” certificate — issuing one publishes the
hostname.
Separately, certificate lifetimes have collapsed. Let's Encrypt issues free certificates valid for 90 days, and the industry is pushing lifetimes shorter still. The point of a 90-day certificate is to force automated renewal: a certificate you rotate by hand every year is one you will eventually forget until it expires at 2 a.m. If you still renew manually, the real fix is automation (ACME), not a calendar reminder.
This tool works in two parts, and its limits follow directly from how browsers work. First,
it opens a real HTTPS connection to the host from your browser; if the TLS handshake
succeeds, the live certificate is currently valid and trusted by your browser.
Second, it enriches that with issuer and expiry details pulled from public Certificate
Transparency logs (via crt.sh).
The honest caveat: because the core check rides on your browser's handshake, it inherits your
browser's leniency. If the server is missing an intermediate but your browser fetches or
caches that intermediate anyway, this check can still pass — even though stricter
clients like curl or a mobile app would fail. For the authoritative chain view,
verify from a clean client, for example
openssl s_client -connect host:443 or curl -v, which will not paper
over a missing intermediate.
Almost always a missing intermediate certificate. Browsers cache or fetch the missing
intermediate for you, so the page loads; stricter clients like curl, Java, and mobile
apps build the chain themselves and fail. Serve the full chain
(fullchain.pem) so every client can reach a trusted root.
No. A certificate only proves control of the hostname and that the connection is encrypted. It says nothing about the operator's honesty — phishing sites routinely hold valid certificates for their own lookalike domains. Treat it as encryption, not endorsement.
Three separate faults: expired means past its valid-until date; hostname mismatch means the certificate isn't issued for the name you visited (check the SAN list, not the deprecated CN); untrusted issuer means the chain doesn't reach a root the client trusts, often a missing intermediate.
Short lifetimes (Let's Encrypt's default is 90 days) exist to force automated renewal via ACME, which limits the damage from a compromised key and removes the human who forgets to renew. If a 90-day certificate is a burden, the answer is automation, not a longer certificate.
Yes. Every publicly trusted certificate is recorded in Certificate Transparency logs,
searchable through services like crt.sh. It is a good way to spot
mis-issuance or shadow subdomains — and a reminder that requesting a certificate
publishes the hostname.
Because this check relies on your browser's handshake, and browsers are lenient —
they fetch or cache missing intermediates. A stricter tool that builds the chain from
scratch will catch a problem your browser papers over. Confirm with
openssl s_client or curl -v for the definitive chain.