How to use it
- Paste a certificate into Certificate: the whole PEM block, or its Base64 alone.
- Read Subject and Issuer to see who the certificate is for and who signed it.
- Check Validity. It counts the days left from today's date in your time zone.
- Compare the SHA-256 fingerprint with the value the site, the vendor or the certificate authority publishes before you trust the certificate.
What a certificate says
An X.509 certificate (RFC 5280) binds a public key to a name and is signed by an issuer. It is written in ASN.1 DER, a tree of tagged values. A PEM block is that DER written in Base64 between a BEGIN and an END line (RFC 7468). The page reads the tree with its own small DER reader and shows each field.
Certificate ::= SEQUENCE { tbsCertificate, signatureAlgorithm, signatureValue }
TBSCertificate ::= SEQUENCE { version [0], serialNumber, signature, issuer,
validity, subject, subjectPublicKeyInfo, ..., extensions [3] }
What the page does not check
The page does not verify the signature, does not build the chain up to a trusted root, does not check whether the certificate was revoked, and does not connect to the host. A certificate can read as valid here and still be rejected by a browser or a server. Those checks need the issuer's public key and a trust store, which this page does not have.
Days left are counted from today's date to the day of the Not after date, both days included. A certificate revoked before its Not after date still shows its dates here, because the page reads no revocation list and asks no OCSP responder.
Fingerprints
A fingerprint is the digest of the whole DER bytes. Two certificates with the same SHA-256 fingerprint are the same certificate. SHA-1 is no longer collision-resistant, so compare the SHA-256 value when you need certainty; the SHA-1 value is shown because many older lists still print it.
Worked example: the E5 intermediate of Let's Encrypt (the default)
The default certificate is the E5 intermediate of Let's Encrypt, signed with ECDSA P-384 by ISRG Root X2. The page reads these fields from it. The validity status depends on the date you read it, so it is not in the table; the other fields are the same on every day.
| Field | Value |
|---|---|
| Version | 3 |
| Serial number | 18:6E:75:D4:EE:B0:A0:5D:FD:2D:A8:20:86:5D:1E:31 |
| Signature algorithm | ECDSA with SHA-384 (1.2.840.10045.4.3.3) |
| Issuer | C=US, O=Internet Security Research Group, CN=ISRG Root X2 |
| Subject | C=US, O=Let's Encrypt, CN=E5 |
| Not before | March 13, 2024 at 12:00:00 AM UTC |
| Not after | March 12, 2027 at 11:59:59 PM UTC |
| Public key | Elliptic curve P-384, 384 bits |
| Key usage | Digital Signature, Certificate Sign, CRL Sign |
| Extended key usage | TLS client authentication, TLS server authentication |
| Basic constraints | CA: yes, path length 0 |
| SHA-256 fingerprint | E7:88:D1:4B:04:36:B5:12:0B:BE:E3:F1:5C:15:BA:DF:08:C1:40:7F:E7:25:68:A4:F1:6F:91:51:C3:80:E1:E3 |
Frequently asked questions
Why does the page say my certificate is valid when my browser says it is not?
The page reads the dates and fields only. A browser also checks the signature, the chain up to a trusted root, the host name and whether the certificate was revoked. Those checks need data this page does not have.
What is the difference between the SHA-1 and SHA-256 fingerprints?
They are two digests of the same DER bytes. SHA-1 is no longer collision-resistant, so SHA-256 is the one to compare when you need certainty. The SHA-1 value is shown because many older lists still print it.
What does a PEM block that starts with BEGIN CERTIFICATE contain?
PEM (RFC 7468) wraps the DER bytes of a certificate in Base64, between a BEGIN line and an END line that both carry the label CERTIFICATE. The page also accepts the Base64 text on its own.
Why is the key size shown in bits for RSA but as a curve for ECDSA?
An RSA key is described by the length of its modulus in bits. An ECDSA key is described by its curve, such as P-256 or P-384, which sets the size of the key.
What does CA: yes, path length 0 mean?
The certificate may sign end-entity certificates, but no further intermediate certificate authorities below it (RFC 5280, section 4.2.1.9). Basic constraints are read from the certificate, not checked against a chain.
Does the page send my certificate anywhere?
No. The DER bytes are read and the fingerprints are computed in your browser. Nothing is uploaded or stored, and the page does not connect to the host named in the certificate.
Sources
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures
- ITU-T X.690: ASN.1 encoding rules (DER)
- Let's Encrypt certificate repository
Figures and text last checked on Tuesday, November 10, 2026.