Verify SSL certificates, check trust status, and inspect security details
Checking certificate for ...
This may take a few seconds
Server Certificate
Common Name
SANs
Valid From
Valid To
Serial Number
Algorithm
Issuer
Connection Details
Protocol
Cipher Suite
Key Exchange
Key Type
Key Size
IP Address
OCSP Stapling
Enabled
Not Supported
HSTS (HTTP Strict Transport Security)
Enabled
Not Enabled
Max Age:
Warnings
•
Certificate Chain
ServerChain
CN:
Org:
Valid:
Issuer:
Subject
Issuer
Fingerprints
SHA-256
SHA-1
Error
About SSL Certificate Checker
Our free SSL Certificate Checker lets you instantly verify any domain's SSL/TLS certificate. Enter a hostname to view its certificate details including issuer, validity dates, key type, cipher suite, protocol version, and full certificate chain. The tool connects directly to the server and retrieves real-time certificate information without any installation or registration required.
How to Use
1Enter the domain name (e.g., google.com) in the input field.
2Optionally change the port (default is 443 for HTTPS).
3Click "Check SSL" and view the complete certificate details.
Use Cases
•Verify SSL certificate installation before going live
•Check certificate expiry dates to prevent downtime
•Always verify the certificate chain is complete — missing intermediates cause browser warnings.
•Check certificate expiry at least 30 days before expiration to allow time for renewal.
•Ensure HSTS is enabled with a max-age of at least 6 months for production domains.
•Use ECDSA certificates for better performance — they're 2-3x faster than RSA.
How the Check Works
Everything on this page comes from one live TLS connection to the host you enter — nothing is read from a cached database, so you always see the certificate the server is presenting right now.
1DNS resolution. The hostname is resolved first and the address is reported next to the certificate, which is how a mismatched A record or a stale CDN endpoint shows up.
2TLS handshake. The connection is made with a verifying SSL context, so an untrusted or incomplete chain fails the handshake instead of being silently accepted. The negotiated protocol version, cipher suite and key-exchange algorithm are read from the live session.
3Chain retrieval. The peer certificate is fetched in binary form and parsed, then the intermediates are requested separately. A host that serves only its leaf produces a one-certificate chain and raises a warning.
4Trust decision. Trust is judged separately from expiry, because a certificate can be perfectly in-date and still untrusted if its issuer is unknown or self-signed.
5OCSP stapling. The handshake is repeated asking for a stapled revocation response. Present means the server is proxying status on behalf of its clients; absent is not a fault, it just costs each client a lookup.
6HSTS. A plain HTTP request is made to the host and the Strict-Transport-Security header is read back, including its max-age.
Reading the trust result
Trusted — the chain verifies against a trusted Certificate Authority.
Not trusted — usually a missing intermediate, a self-signed leaf, or a private CA this checker does not carry.
Hostname mismatch — the certificate does not list the host you asked for, which browsers treat as a hard error.
Reading the warnings
Expired or not-yet-valid certificates, compared in UTC against notBefore and notAfter.
A legacy protocol version or weak cipher negotiated during the handshake.
A chain of length one, meaning no intermediate was sent at all.
HSTS missing entirely, or present with a max-age short enough that a browser restart forgets it.
One caveat worth knowing: this reports the certificate a visitor receives. A CDN or load balancer in front of your origin terminates TLS with its own certificate, so an expiring edge certificate will show up here even when your origin is perfectly healthy — which is exactly what your users see.
Frequently Asked Questions
It means the chain does not verify against a trusted Certificate Authority. In practice this is almost always a server that sends only its leaf certificate instead of the full chain, so clients cannot find the intermediate that links it to a known root. The other two causes are a self-signed certificate, which is reasonable on an internal network but never on the public internet, and a certificate from a private CA that browsers do not carry. All three end in a full-page browser warning.
Check it on every deployment, because a release is the most common moment for the wrong certificate file to be picked up or for none to be deployed at all. After that, automate it: a daily job with alerts at 30, 14 and 3 days remaining covers almost every real expiry. Certificate lifetimes now run from weeks (Let's Encrypt) to a year (commercial CAs), so the failure you are guarding against is a renewal that silently never ran rather than an expiry you were not warned about.
Normally every browser has to ask the certificate authority whether your certificate has been revoked, adding a round trip to each handshake and revealing your visitors to the CA. Stapling lets the server fetch that status once and hand it to clients during the handshake instead. It is a performance and privacy improvement rather than a security requirement, so a missing staple will not break anything — it just means every visitor pays the extra lookup.
Nearly always because a CDN or load balancer sits in front of your server and terminates the connection with its own certificate. This tool reports what a visitor actually receives, not what your origin holds, so compare against the CDN's certificate tooling. The other cause is a stale certificate left in place after a renewal: if your dashboard shows a newer issue date than the live certificate, the renewed file was generated but never deployed.
They are one certificate in two encodings. DER is the binary form that TLS puts on the wire, and it is what this tool parses directly from the handshake. PEM wraps those same bytes in BEGIN and END CERTIFICATE markers and Base64-encodes them so the file stays readable and copy-pasteable. Nothing about the certificate changes between the two, only how it is stored. A server that accepts a PEM file but rejects a DER one has a file-format mismatch, not a different certificate.
A wildcard replaces exactly one label. *.example.com matches shop.example.com but not eu.shop.example.com, and never the bare example.com itself. Public CAs will not issue a wildcard spanning two levels at all, so a host like that needs its own certificate listing every name as a separate SAN.
For anything a browser loads over HTTPS, yes. Visitors get a full-page interstitial with no way past it unless they are technical enough to click through, and search engines can drop those pages from the index. API and mail clients fail outright with a certificate verification error rather than degrading. The one case that keeps working is an expired certificate on a host that has silently fallen back to plain HTTP, which is worth fixing but not a security model anyone wants.
Not on this page — it tests the live endpoint on purpose, which is why it can tell you about the chain, stapling and HSTS that a file cannot show. To inspect a certificate file you already have, use the Certificate Decoder instead: paste the PEM or PFX and it lists the subject, issuer, validity dates, SANs, key details and fingerprints without needing the server to be reachable.
