About Certificate Parser
Certificate Parser reads an X.509 certificate from PEM text, a DER file, or a PKCS#12 bundle and lays out what is actually inside it: subject and issuer, serial, validity window, public key, signature algorithm OID, subject alternative names, key usage, the SHA-256 fingerprint, and whether the certificate is a CA. When you paste more than one certificate it also runs a basic chain check in the order you supplied them.
Almost every TLS incident comes down to a question the file itself can answer: which names does this certificate cover, when does it expire, who signed it, and is it the same certificate the other environment serves. Reading those fields is not the same as establishing trust, which also requires a path to a root the client already trusts, a hostname matching a SAN, an unrevoked serial, and a server that sends its intermediates. This tool answers the first set of questions and does not claim to answer the second.
How to use this developer tool
- Paste one or more PEM blocks into the text area, or choose a .pem, .crt, .cer, .der, .p12, or .pfx file.
- For a PKCS#12 bundle, type its password in the password field first; the format is selected from the file extension, so keep the .p12 or .pfx name.
- Run the parser and read each certificate card from the top: subject and issuer tell you whether it is self-signed, the SAN list tells you which hostnames it covers.
- Check the status pill for an expired certificate, one expiring within 30 days, or a subject that equals the issuer.
- Compare the SHA-256 fingerprint against the one the server is serving when you need to prove two environments have the same certificate.
Worked example: a self-signed certificate for two hostnames
This is a real certificate generated for a staging host. The parser output below is exactly what the tool renders for it.
-----BEGIN CERTIFICATE-----
MIIDvDCCAqSgAwIBAgIUKVLmx56R9EdcxqKTrrfh4PIf81MwDQYJKoZIhvcNAQEL
BQAwPjELMAkGA1UEBhMCREUxFTATBgNVBAoMDEV4YW1wbGUgR21iSDEYMBYGA1UE
AwwPYXBpLmV4YW1wbGUuY29tMB4XDTI2MDkyMTA3MDQ1M1oXDTI3MDkyMTA3MDQ1
M1owPjELMAkGA1UEBhMCREUxFTATBgNVBAoMDEV4YW1wbGUgR21iSDEYMBYGA1UE
AwwPYXBpLmV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA07x10ZyWzNfGA2Jkkoe7TcOCT/x3q9Rf8DcsiISGO5jBNTwp+lp3sGLxOGnL
dmSbRh5MkL3o66HtVC+e3G/bll34JbwuUIjlJiLGLCj/UReG3HoolrDOlzTY9TMx
h9z8scbvZIUTCok+iCGdQjTt2ii+EDkCv2V8wCUKDcvqniQX13dvd7XQpLL9ucKb
OqAcRAN1FXhjzXOyhEDf5GQjOryZlwhGRdQRIboMv2aFyrPK2mcOrNQuHjLwc9EE
FZApSGRKZIcND/gCllB9t9VI3NhZIrn9t4sINXBXzwymD1Mcr9WdqyWpYTKzxPci
wPkIvy5r3GU17rwR4ez9dcwPGQIDAQABo4GxMIGuMB0GA1UdDgQWBBRAXYdd/YCb
g0+A+Mo20U8GULwiWDAfBgNVHSMEGDAWgBRAXYdd/YCbg0+A+Mo20U8GULwiWDAv
BgNVHREEKDAmgg9hcGkuZXhhbXBsZS5jb22CE3d3dy5hcGkuZXhhbXBsZS5jb20w
DgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAM
BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQB74CIo9R5iVScxKXkkGFjm
otjYpKdhArpe998fm14v9rNeHrJzsfb6AitA/5X0GnyJI7QxvhJ5td97r3dIq3x7
8fz8OwZ9+IDQszMetNrLTScWlZfGL2P4SX2cNwJAY/9kE3qxq6BZRcWh+8Znu5Ut
Ei+oHZXupIRvv0GgoaGE48cX3VKEw353SVM73ual7vfFmM6PpfaRrihlEp5jDWK4
FxsO1dxc15rCc0wsqBzWhMCqP9a9GAjqJze334mk59t3EF7FPVHXUaEy5QrHkSNv
VTkb6QNOGbJYAemu3/f3z9T8yR1AfHKjNKg1mrboMJNO2eyvSpIUWpP8ByU1Tep5
-----END CERTIFICATE-----Subject C=DE, O=Example GmbH, CN=api.example.com
Issuer C=DE, O=Example GmbH, CN=api.example.com
Serial 2952e6c79e91f4475cc6a293aeb7e1e0f21ff353
Validity 2026-09-21T07:04:53.000Z → 2027-09-21T07:04:53.000Z
Public key RSA 2048 bit
Signature alg OID 1.2.840.113549.1.1.11
SAN api.example.com, www.api.example.com
Key Usage digitalSignature, keyEncipherment
Extended Usage serverAuth, clientAuth
SHA-256 96:7D:CA:32:0A:59:C0:9B:BD:8F:5E:AA:CA:7F:55:85:BC:C2:7A:E6:D8:3A:72:0A:B5:BB:71:BA:BB:48:42:FB
CA No
Status possibly self-signedSubject equals issuer, so nothing but this certificate vouches for it, which is why the status pill says self-signed. The OID 1.2.840.113549.1.1.11 is sha256WithRSAEncryption; the tool prints the raw OID rather than a friendly name, so the reference table below is the lookup you need.
Certificate files and signature OIDs
The top rows explain what a given extension normally contains; the bottom rows decode the signature algorithm OID the parser prints.
| Item | Encoding or meaning | Contains / notes |
|---|---|---|
| .pem, .crt, .cer | Base64 DER between BEGIN/END lines | One or more certificates; opens here |
| .der | raw DER binary | Exactly one certificate; opens here |
| .p12, .pfx | PKCS#12, password protected | Certificate chain plus, usually, the private key; only certificates are shown here |
| .key | PEM or DER private key | Never needed for inspection; not parsed here |
| .csr | PKCS#10 request | A request, not a certificate; use openssl req -text |
| .p7b, .jks | PKCS#7 / Java keystore | Chain containers; not supported here, convert with openssl or keytool |
| 1.2.840.113549.1.1.11 | sha256WithRSAEncryption | Current default for RSA certificates |
| 1.2.840.113549.1.1.5 | sha1WithRSAEncryption | Deprecated; rejected by modern clients |
| 1.2.840.10045.4.3.2 | ecdsa-with-SHA256 | ECDSA certificate; see the first troubleshooting entry |
Troubleshooting
A modern ECDSA certificate is rejected as invalid.
Why it happens The parser is built on a library that reads RSA public keys only. An EC certificate fails while reading the SubjectPublicKeyInfo, before any field can be displayed, and surfaces as a generic invalid-certificate error.
Fix Inspect EC and Ed25519 certificates with openssl x509 -in cert.pem -text -noout. RSA certificates, which still dominate internal PKI and many issuers, parse normally here.
A PKCS#12 file with the right password does not open.
Why it happens The format is chosen from the file name: only names ending in .p12 or .pfx take the PKCS#12 path. A bundle renamed to .cer or downloaded without an extension is treated as PEM or DER and fails.
Fix Restore the .p12 or .pfx extension before selecting the file. A genuinely wrong password produces a distinct failure, since the PKCS#12 MAC cannot be verified.
The chain check fails on a chain that servers accept.
Why it happens The check treats the last certificate you pasted as the trust anchor and verifies the list in the order given. Leaf first, then intermediates, then root is the expected order; a bundle that starts with the root, or one missing the issuer of the leaf, cannot be verified this way.
Fix Reorder the file leaf to root, and add the issuing intermediate if the bundle omits it. The result only proves that the pasted certificates sign each other, not that any client trusts the anchor.
Everything parses, yet browsers still show a warning.
Why it happens Parsing reports contents. A warning usually means the hostname is not in the SAN list, the server does not send the intermediate, the root is not in the client's trust store, or the clock is wrong.
Fix Compare the SAN list against the hostname you are visiting, then check what the server actually sends with openssl s_client -connect host:443 -showcerts.
When this tool is the right choice
- Checking the expiry date and SAN list before or after a renewal.
- Proving that staging and production serve the same certificate by comparing SHA-256 fingerprints.
- Confirming the order and completeness of a bundle you are about to deploy.
- Reading the certificate out of a PKCS#12 file a colleague emailed you, without importing it into a keychain.
When to use something else
- Deciding whether a certificate is trusted. Only a client with a trust store can answer that; use openssl s_client or the browser's own certificate viewer.
- Inspecting ECDSA or Ed25519 certificates, certificate signing requests, or private keys; openssl handles all three.
- Testing a live endpoint's TLS configuration. The Website Check tool tells you whether a host responds; this tool never opens a connection.
Privacy and data handling
Parsing, PKCS#12 decryption, and fingerprint calculation all run in this browser tab; the password you type is used as an in-memory decryption key and is never stored or transmitted. Certificates are public by nature, so the file itself is not the sensitive part. A PKCS#12 bundle is different: it usually carries the private key as well, so use a copy you can afford to lose.
Related developer tools
Frequently asked questions
Does parsing a certificate verify it?
No. Parsing decodes the structure and shows you the fields. Verification means checking a signature chain against a trusted root, matching the hostname, and honouring validity and revocation, none of which a decoder can decide on its own.
What is the SHA-256 fingerprint for?
It is the digest of the whole DER-encoded certificate, so two files with the same fingerprint are the same certificate. That makes it the fastest way to confirm a deployment picked up the file you meant.
Is my PKCS#12 password sent anywhere?
No. It is passed straight to the local decryption routine in this tab and discarded with the page. That said, the file itself normally contains a private key, so treat it with the same care as the key.
What does the self-signed warning actually mean?
It means the subject and issuer fields are identical, so the certificate vouches for itself. That is expected for a root CA or a local development certificate, and a problem if you expected a public issuer.
In what order should a chain file be pasted?
Leaf certificate first, then each intermediate, then the root, which is the same order a TLS server sends them. The chain check builds its trust anchor from the last entry, so a reversed file reports a failure.
Why is the signature shown as a number?
The parser prints the raw algorithm OID from the certificate instead of translating it. The reference table above maps the three you will meet most often; anything beginning with 1.2.840.113549.1.1 is RSA, and 1.2.840.10045.4.3 is ECDSA.