Paste a certificate, a whole chain or a certificate signing request and read it in plain words: who it was issued to, which names it covers, when it expires, what key it uses and whether the chain is in the right order. PEM, DER and Base64 without the header lines all work, and so does a dropped .cer, .crt, .csr or .p7b file. Everything is decoded in your browser; nothing is uploaded.
Paste a certificate or CSR: subject, SAN, validity, key and chain order, decoded in your browser.
Runs in your browserOr drop a .pem, .crt, .cer, .der, .csr, .req, .p7b or .p7c file here. Files are read in your browser and never uploaded. Private keys and .pfx files are refused.
How to use
- Paste one or more
-----BEGIN CERTIFICATE-----blocks, or a-----BEGIN CERTIFICATE REQUEST-----block. You can also use Open a file or drop a file on the tool. - Read the summary card first: names, validity with the days left, key and purpose. For a chain there is one card per certificate, leaf first.
- Check the warning lines under it. Each one names a single problem: expired, no SAN, a weak signature, a chain in the wrong order.
- Use Check it yourself to get the OpenSSL, certutil and PowerShell commands that show the same fields on your own machine.
- Use Share link to send a colleague the exact decode. The link carries the certificate in the part after
#, which browsers never send to a server.
What the decoder checks
| Check | What triggers it | What it means for you |
|---|---|---|
| Validity | Expired, not yet valid, or fewer than 30 days left. | Renew now; an expired certificate breaks every client at once. |
| Subject Alternative Name | A server certificate with no SAN. | Browsers ignore the Common Name. Without SAN entries the certificate matches no name at all. |
| Signature | SHA-1 or MD5. | Clients reject it. Reissue with SHA-256. |
| Key | RSA shorter than 2048 bits. | Too weak for public trust. Generate a new key and a new request. |
| Lifetime | Longer than the CA/Browser Forum maximum for public TLS certificates. | Information only: a public CA would not issue it. Certificates from your own internal CA are not bound by this rule. |
| Chain order | Each certificate should be issued by the next one. | The decoder shows where the order breaks and the order that works. It compares names and key identifiers; it does not verify signatures. |
| Private keys | Any private key or .pfx file. | Refused before it is read, and never put into a share link. |
FAQ
Frequently asked questions
Yes. A certificate and a signing request are public by design: the server sends its certificate to every client that connects. The decoder runs entirely in your browser and makes no network request with what you paste. What must never be pasted anywhere is the private key, and the tool refuses one if you try.
A server should send its own certificate first, then the intermediate that issued it, and so on towards the root. Many servers are configured with the files in the opposite order, and some clients then fail to build the chain. The decoder compares each certificate’s issuer with the next one’s subject and key identifiers, and shows the order that works.
No. It reads the certificate and compares names; it does not verify the cryptographic signatures and it does not contact the CA to check revocation, because that would need the network. To test the full chain as clients see it, use openssl s_client or the Website and host checker, which reads the certificate the server actually sends.
The CA/Browser Forum has been shortening the maximum lifetime of publicly trusted TLS certificates. A certificate issued before a cut-off date stays valid for the lifetime it was issued with. The line is information about the rule today, not an error about the certificate you pasted.
openssl x509, certutil -dump and the .NET X509Certificate2 class read only the first certificate in a file. For a whole bundle use openssl storeutl -noout -text -certs bundle.pem, which the tool also shows under Check it yourself.
PEM and DER are encodings; CRT and CER are only file extensions. DER is the certificate in binary. PEM is the same bytes in Base64 between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. A .crt or .cer file can contain either, so open it in a text editor: readable header lines mean PEM, unreadable bytes mean DER. The decoder accepts both.
With OpenSSL: openssl x509 -inform der -in cert.cer -out cert.pem, and openssl x509 -in cert.pem -outform der -out cert.cer for the other direction. On Windows without OpenSSL: certutil -encode cert.cer cert.pem and certutil -decode cert.pem cert.cer.
Run openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts and copy the BEGIN CERTIFICATE blocks it prints, in the order it prints them. Or check the host with the Website and host checker, or export the certificate from the browser padlock. On a Windows server, the certificates in the machine store are listed by Get-ChildItem Cert:\LocalMachine\My | Format-List Subject, NotAfter, Thumbprint.
Public CAs do not sign server certificates with their root; they use an intermediate CA, and clients trust the root. The server must send its own certificate and the intermediate, so the client can build the path up to a root it already trusts. A server that sends only its own certificate works in some browsers and fails in other clients. Paste what the server sends and the decoder shows whether the intermediate is there.
No to both. A wildcard matches exactly one label in its position: *.example.com covers www.example.com and mail.example.com, but not the bare example.com and not a.b.example.com. That is why certificates such as zaur.it’s list both *.zaur.it and zaur.it in the SAN.
The Thumbprint field in the Windows certificate console is the SHA-1 hash of the certificate’s DER bytes. The decoder shows it as the SHA-1 fingerprint, with colons; remove the colons and compare it with the value in certlm.msc or with Get-ChildItem Cert:\LocalMachine\My. The SHA-256 fingerprint is the better value to compare when both sides support it.
They limit what the certificate may be used for. Key usage is the low-level permission, such as digital signature or key encipherment. Extended key usage names the purpose: Server Authentication for a web or RDP server, Client Authentication for a user or device, Code Signing for software. When the extended key usage list is present but does not include Server Authentication, TLS clients reject the certificate as a server certificate.
Four things: every name the server answers to is in the SAN list (the CN alone is not enough), the key is RSA 2048 bits or more or an EC P-256 or P-384 key, the request is signed with SHA-256, and the subject fields match what your CA expects. Most public CAs replace the subject with what they validated, but a missing SAN name means a new request and a reissue.
Yes. A .p7b or .p7c file is a PKCS #7 bundle: the format Windows uses when you export a certificate “with all certificates in the certification path”, and the one many CAs send chains in. The decoder reads it in DER or PEM form and shows every certificate in it. A PKCS #7 bundle does not store an order, so the decoder shows the leaf first and says so. On your own machine, openssl pkcs7 -in chain.p7b -inform der -print_certs -noout lists the same certificates.
A .pfx or .p12 file contains the private key, so it does not belong on a website. Export only the certificate on your machine: openssl pkcs12 -in file.pfx -nokeys -out cert.pem, or in the Windows certificate console export it without the private key. Then paste cert.pem.
Practical examples
Example 1: what zaur.it actually serves. The leaf covers *.zaur.it and zaur.it, is issued by a Sectigo DV intermediate and is followed by that intermediate: two cards, chain order correct, days left shown. This is the certificate pair the Example button loads. Open this decode.
Example 2: a chain in the wrong order. The intermediate comes first and the leaf second, as it often ends up in a bundle file assembled by hand. The decoder says where the order breaks and which order works. Browsers are forgiving about chain order; many other TLS clients are not. Open this decode.
Example 3: check a CSR before it goes to the CA. A request with two DNS names in the SAN. Before you submit a request, confirm that every name is in the SAN list, the key is 2048 bits or more and the request is signed with SHA-256; a mistake here costs a reissue. Open this decode. Compare it with a request that has no SAN at all: open the CSR without SAN.
More test cases, including expired, SHA-1 signed and self-signed certificates, EC and Ed25519 keys and a PKCS #7 bundle, are in the Load a sample list and on the sample certificates page, where every file can be downloaded with its SHA-256 checksum.
Useful links
- RFC 5280: X.509 certificate and CRL profile
- CA/Browser Forum Baseline Requirements for TLS server certificates
- openssl x509 manual
- certutil reference (Microsoft Learn)
Other tools
- Website and host checker: see the certificate a server actually sends, and its days left
- Base64 encoder Pro: PEM is Base64 of the DER bytes; decode it to the binary file
- Hash generator: compute hashes in your browser
- All security tools
Related guides
- Sample certificates for testing: valid and broken certificates, chains and CSRs to download, with checksums.
- How to Generate SSL Certificates with OpenSSL: keys, requests and self-signed certificates from the command line.
- Discovering Certificate Authorities (CAs) in Your Domain: find the internal CAs that issued what you are decoding.
- certutil -encode and -decode: Base64 encoding files from the Windows command line: turn a PEM file into DER and back on Windows.
- OpenSSL Cheat Sheet: the OpenSSL commands for keys, requests and certificates, on one printable page.