What does this certificate actually say?
Paste a PEM or DER certificate and read it: subject, issuer, validity, alternative names, key, extensions and fingerprint. Parsed in your browser, and nothing is sent anywhere.
Everything below is what the certificate claims about itself. Nothing here checks that it was issued by anyone you trust, that the chain up to a root is intact, that it has not been revoked, or that its name matches a site you were visiting. A self-signed certificate claiming to be your bank parses perfectly.
openssl s_client -connect example.com:443 </dev/null | openssl x509
Subject — who it is about
Issuer — who signed it
Names this certificate covers
The certificate
Public key
Extensions
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
Why the common name is not the answer any more
Browsers stopped looking at the subject's common name for host matching years ago. What they check is the subject alternative names extension, and a certificate without one is rejected regardless of what its common name says.
This matters when a certificate looks correct and does not work: the common name says example.com, the SAN list says www.example.com only, and the bare domain fails. The SAN list is shown above on its own for that reason.
The two-digit year trap
X.509 encodes dates before 2050 as UTCTime, which carries only two digits of year. RFC 5280 pins the interpretation: 50 and above means 19xx, below means 20xx. An implementation that gets that backwards turns a certificate expiring in 2049 into one that expired in 1949, and nothing complains until a certificate happens to land on the wrong side of it.
The parser here follows the RFC and the tests check all four corners of the rule.
What is checked and what is only read
Read and reported: version, serial, both names, validity dates, the public key, the signature algorithm, and every extension — with the four that matter most decoded and the rest listed by object identifier rather than guessed at.
Checked: that the signature algorithm recorded inside the signed portion matches the one outside it, which RFC 5280 requires and a malformed certificate can violate.
Not done at all: chain building, signature verification, revocation checking, name matching, or any trust decision. Those need the issuer's certificate, a trust store, and a network connection — and this page has none of the three by design.
What this tool does not claim
No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.
Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.
Getting a certificate to look at
From a live site: openssl s_client -connect example.com:443 </dev/null | openssl x509 prints the leaf certificate in PEM. Add -showcerts to see the whole chain the server sent.
From a browser: click the padlock, view the certificate details, and export. Every major browser offers this, though the wording varies.
From a file: .crt, .cer and .pem are usually PEM and can be pasted directly. .der is binary — convert it first with the PEM/DER converter.
Reading the dates
Certificates for public web servers are capped at just over a year, and that limit has been falling. A certificate valid for ten years is either an internal one, a CA root, or something that will not be accepted by a browser.
"Not yet valid" almost always means a clock is wrong rather than a certificate is. Check the machine complaining before the certificate.
Related
The public key inspector for a key on its own, the PEM/DER converter for format changes, or everything else.
Questions people actually ask
Does this tell me whether a certificate is trusted?
No, and that is the most important thing on the page. It reads what the certificate says about itself. It does not build a chain to a root, verify any signature, check revocation, or match the name against a site — those need the issuer's certificate, a trust store and a network connection, none of which this page has. A self-signed certificate claiming to be your bank parses perfectly.
Why does it show subject alternative names separately?
Because that is what browsers actually check. Host matching against the subject's common name was dropped years ago, and a certificate without a SAN extension is rejected whatever its common name says. The commonest confusing case is a certificate whose common name is example.com but whose SAN list only has www.example.com.
What does "not yet valid" mean?
Almost always that a clock is wrong, not that the certificate is. Check the machine complaining before you check the certificate.
How do I get a certificate from a website?
openssl s_client -connect example.com:443
It says the extension is unrecognised.
Then it is one this tool does not decode, and it is listed by its object identifier rather than guessed at. The four that matter for most purposes — subject alternative names, key usage, extended key usage and basic constraints — are decoded; the rest are named where the identifier is known and reported raw otherwise.
Is the certificate uploaded?
No. It is parsed by code running in your browser and nothing is transmitted. Certificates are public documents, but the promise is the same as everywhere else on this site.