PEM · CRT · DER
Paste a certificate or a full chain, or load a .crt, .cer or .der file, to read its validity and days left, covered names, issuer, key, serial and fingerprints. When the issuer is in the same paste, each signature is checked against it. All of it runs on this page, so nothing is uploaded.
Decoded in this browser tab. Nothing you paste or load is uploaded, stored or logged. PEM text, a whole chain, or a binary .der/.cer file all work.
Paste one certificate or a whole chain that starts with -----BEGIN CERTIFICATE----- to see its dates, names, issuer, key and fingerprints.
These are the fields that decide whether a certificate works, in the order you usually need them.
| Field | What it tells you |
|---|---|
| Valid from / valid until | The notBefore and notAfter times in UTC, with whole days left rounded down, counted the same way as the live expiry checker. |
| Subject and SANs | Who the certificate is for. Browsers match the hostname against the subject alternative names only. |
| Issuer | The certificate authority that signed it. A root CA names itself as its issuer. |
| Serial number | Unique for each issuing CA. It is what a revocation list, or a CA's support team, will ask you for. |
| Key type and size | RSA bits or the ECDSA curve. RSA keys under 2048 bits are flagged. |
| Signature algorithm | How the issuer signed it, such as ECDSA with SHA-384. SHA-1 on anything but a root is flagged. |
| Key usage and extended key usage | What the key may be used for. A website certificate needs TLS server authentication in its extended key usage. |
| Basic constraints | Whether it is a CA certificate, and how many CAs may sit below it (the path length). |
| SHA-256 and SHA-1 fingerprints | Hashes of the whole certificate, for telling two certificates apart. Windows calls the SHA-1 value the thumbprint. |
| Public key SHA-256 | A hash of the public key alone. It matches the CSR and private key the certificate was issued for, and stays the same across a renewal that reuses the key. |
The terminal equivalents. Each command was run against the sample leaf certificate on this page with OpenSSL 3.
openssl x509 -in cert.pem -noout -subject -issuer -dates -serialsubject=CN = www.beacon-demo.test
issuer=C = GB, O = ExpiryBeacon Test, CN = ExpiryBeacon Test Issuing E1
notBefore=Oct 29 16:33:55 2026 GMT
notAfter=Oct 26 16:33:55 2036 GMT
serial=04A1B2C3D4E5F60718293A4B5C6D7E8F90openssl x509 -in cert.pem -noout -fingerprint -sha256sha256 Fingerprint=66:B4:02:45:4D:3B:5D:2F:74:1F:1A:8E:09:5D:AA:6B:1F:F0:6B:07:ED:A2:40:53:D8:2F:3D:2D:2B:CA:79:B9Use -sha1 for the SHA-1 fingerprint. The decoder shows both.
openssl x509 -inform der -in cert.der -noout -subject -enddatesubject=CN = www.beacon-demo.test
notAfter=Oct 26 16:33:55 2036 GMTConvert DER to PEM with openssl x509 -inform der -in cert.der -out cert.pem, or the other way with -outform der.
A server should send its own certificate first, then each intermediate in order, each one signed by the next. Paste the whole bundle and the decoder lists every certificate, works out which one issued which, and checks each signature with the issuer's public key.
The root does not need to be sent, because clients already hold the roots they trust; including it only adds bytes to every handshake. A bundle that starts with an intermediate, lists certificates out of order, or repeats one is flagged.
The failure this catches most often is a missing intermediate. Browsers that cached the intermediate from another site carry on working, while API clients and freshly installed devices fail. That is also why the live checker reports how many certificates the server actually sent.
Two questions the decoder answers in the browser, asked from a terminal instead.
openssl verify -CAfile root.pem -untrusted intermediate.pem cert.pemcert.pem: OKopenssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform der | openssl dgst -sha256
openssl pkey -in cert.key -pubout -outform der | openssl dgst -sha256SHA2-256(stdin)= 6a2c1a1b949461de074872fcac51d05c47d75ffa21f10a45537e33ac037247d9
SHA2-256(stdin)= 6a2c1a1b949461de074872fcac51d05c47d75ffa21f10a45537e33ac037247d9Matching hashes mean the key and certificate belong together. The first value is the Public key SHA-256 the decoder shows.
openssl pkcs7 -inform der -print_certs -in chain.p7bDrop -inform der when the .p7b is PEM text. The printed certificates can be pasted straight into the decoder.
Problems come first, then warnings, then notes that are worth knowing but not urgent.
A correct file is half the job. The other half is the server actually presenting it, and renewing it in time.
Confirm the names, dates and issuer are the ones you expected before you look anywhere else.
A renewed file on disk does not mean the server reloaded it. The SSL certificate checker makes a real handshake and shows the serial and SHA-256 fingerprint that is actually served, so you can compare them with this file.
Save the hostname as a monitor for a daily check, and an email before it reaches your warning window.
DER is the binary encoding of a certificate. PEM is the same bytes in base64, between BEGIN CERTIFICATE and END CERTIFICATE lines. .crt and .cer are only file extensions and can hold either, so the decoder accepts both, pasted or loaded as a file.
No. The file is read and decoded by this page in your browser, and the fingerprints and signature checks use your browser's Web Crypto API. Certificates are public anyway, but private keys are not: if you paste one by mistake, the decoder refuses to read it.
The decoder reads the file you give it. Your server may still be presenting an older certificate, because it was not reloaded after the renewal, or another server behind the same name still has the old file. The live checker shows what the server actually sends.
Not directly. Extract the certificates first with openssl pkcs12 -in file.pfx -nokeys -out cert.pem, or openssl pkcs7 -print_certs -in bundle.p7b (add -inform der for a binary .p7b), then paste the result.
Mostly identification: Windows shows it as the certificate thumbprint, and some appliances still refer to certificates by it. It is a hash of the certificate, not its signature, so seeing one does not mean the certificate is signed with SHA-1.