Certificate viewer: who it is for, who signed it, when it expires
Drop a certificate (.pem, .crt, .cer, DER or base64), a whole chain, a certificate signing request (CSR), a .p7b bundle or a password-protected .p12/.pfx file. You get the subject, issuer, expiry date with the days left, every name it covers, the key type and size, the fingerprints, and for a chain a real signature check of each link.
The file is read on your device. It is never uploaded, and a private key is never shown.
What it shows
- For every certificate: the subject (who it is for) and issuer (who signed it) as full names, the not-before and not-after dates in UTC with the days left (an expired one says EXPIRED and how long ago), every subject alternative name (the DNS names, IP addresses and e-mail addresses it is valid for), the key type and size (RSA 2048, EC P-256, Ed25519…), the signature algorithm, key usage and extended key usage, basic constraints (can it sign other certificates?), the serial number, and the SHA-256 and SHA-1 fingerprints.
- Also: the public-key pin (the base64 SHA-256 of the key that
curl --pinnedpubkeyand Android pinning use), subject and authority key IDs, the OCSP, CA-issuer and CRL addresses it names (listed, never contacted), policies such as "Domain validated" or "Extended validation", and how many Certificate Transparency timestamps it carries. - For a chain (several certificates in one .pem, a .p7b, or the certificates inside a .p12): whether each certificate's issuer name matches the next one's subject, and whether its signature really verifies with the next one's public key, checked with your browser's WebCrypto. An out-of-order file is named as such.
- For a CSR (PKCS#10): the subject and the names it asks for, the key, any requested key usages, and whether the request's own signature is valid, that is, whether it was made with the private key that matches its public key.
- For a private key (PKCS#8, PKCS#1 "RSA PRIVATE KEY", SEC1 "EC PRIVATE KEY", OpenSSH, encrypted or not): its type and size only, and a warning. None of its bytes are put on the page. If you paste one into the box above, the box is emptied.
- Save: any certificate as .pem or as DER .cer, and a whole chain as one chain.pem. That is also how to get the certificates out of a .p12 or .p7b file without OpenSSL.
Files it opens
| File | What is inside | How it is recognised |
|---|---|---|
| .pem .crt .cer (text) | certificates, keys or a CSR, base64 between BEGIN/END lines | -----BEGIN CERTIFICATE-----, also after OpenSSL's "Bag Attributes" lines |
| .cer .crt .der (binary) | one certificate in DER | 30 82 then the X.509 version field A0 03 02 01 02 |
| .csr .req | a certificate signing request (PKCS#10) | PEM CERTIFICATE REQUEST, or DER version 0, a name and a key |
| .p7b .p7c | a certificate bundle (PKCS#7 / CMS signed data), as Windows exports chains | the OID 1.2.840.113549.1.7.2 |
| .p12 .pfx | certificates plus a private key, under a password (PKCS#12) | DER version 3, then a PKCS#7 data OID |
| .key | a private key: PKCS#8, PKCS#1, SEC1 or OpenSSH | its BEGIN line, or its DER shape |
Which .p12 and .pfx files open
A .p12 file encrypts its certificates and its key separately, often with different ciphers, and the choice depends on the program that wrote it. Before you type a password, the page lists each part's scheme and whether it opens here.
| Scheme | Written by | Opens here? |
|---|---|---|
| PBES2, PBKDF2 + AES-256-CBC, SHA-256 MAC | OpenSSL 3 by default, Windows "AES256-SHA256" export, Java keytool | yes (WebCrypto) |
| pbeWithSHAAnd3-KeyTripleDES-CBC | Windows "TripleDES-SHA1" export; OpenSSL 1.x and many other tools for the key part | yes (3DES written here) |
| pbeWithSHAAnd40BitRC2-CBC | OpenSSL 1.x (and openssl pkcs12 -legacy) for the certificate part | yes (RC2 written here) |
| 128-bit RC2, 40- and 128-bit RC4, 2-key 3DES | very old tools | yes |
| PBES2 with AES-192-CBC | rare | depends on the browser: Chrome and Edge have no 192-bit AES |
| PBES1 with MD5 or MD2 (pbeWithMD5AndDES-CBC, pbeWithMD5AndRC2-CBC) | very old Java and OpenSSL | no: browsers have no MD5 |
| GOST 28147-89, Kuznyechik, SM4, Camellia, scrypt | CryptoPro, Chinese national tools, some OpenSSL builds | no, named only |
| PBMAC1 integrity check (RFC 9579) | OpenSSL 3.4 with -pbmac1_pbkdf2 | the contents open; the check is skipped and the page says so |
The password is checked first against the file's integrity code (MAC), so a wrong password is reported as wrong rather than as a damaged file.
A worked example: Let's Encrypt's root
The file isrgrootx1.pem from letsencrypt.org/certs/ is 1,939 bytes. It opens as C=US, O=Internet Security Research Group, CN=ISRG Root X1, issued by itself, valid from 2015-06-04 11:04:38 UTC until 2035-06-04 11:04:38 UTC, with a 4096-bit RSA key, sha256WithRSAEncryption, key usage "Certificate signing, CRL signing", CA: yes with no path limit, and SHA-256 fingerprint 96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6. Its self-signature verifies.
Put the intermediate r11.pem in front of it in one file and you get a two-link chain: R11 (C=US, O=Let's Encrypt, CN=R11, RSA 2048, valid until 2027-03-12 23:59:59 UTC, CA: yes, at most 0 more CA levels) names ISRG Root X1 as its issuer, the names match byte for byte, and R11's signature verifies with the root's key. That fingerprint is how you tell a real ISRG Root X1 from a look-alike with the same name: compare it with the one Let's Encrypt publishes.
What this cannot do
- No revocation check. Whether a certificate has been revoked is answered by the issuer's OCSP responder or CRL, and asking them needs the network. This page makes no request at all: the OCSP and CRL addresses are listed so you can check them yourself (
openssl ocsp, or the CA's own site). A revoked certificate looks exactly like a good one here. - No trust verdict. A verified chain means each certificate was signed by the next one's key. Whether your browser, phone or server trusts the root at the top depends on its own trust store, which a web page cannot read. A home-made CA and a public CA look the same here.
- No fetching of missing intermediates. If the issuer's certificate is not in the file, its signature is not checked; the page does not download it from the "CA issuers" address.
- Hostname rules are not applied. The SANs are listed, but the page does not decide whether a name you type is covered (wildcard rules, name constraints).
- Signatures WebCrypto cannot check are named, not verified: MD5 and MD2 with RSA, SHA-224, DSA, ECDSA on curves other than P-256, P-384 and P-521 (secp256k1, brainpool), SM2 and GOST. Ed25519 and Ed448 are checked where the browser supports them (Ed448 is missing from Chrome).
- .p12 files with unsupported schemes (the MD5 and MD2 PBES1 schemes, GOST 28147-89, Kuznyechik, SM4, Camellia, scrypt, and AES-192 in Chrome and Edge), and .p12 files protected by a recipient's certificate instead of a password, do not open. Their schemes are named before you type anything.
- Encrypted private keys stay encrypted. An "ENCRYPTED PRIVATE KEY" or an old OpenSSL key with a DEK-Info line shows its encryption scheme; its type and size are inside the encryption and are not shown. A private key is never displayed, converted or saved here.
- Not a live server check. It reads the file you give it. It cannot connect to a website to see what certificate the site is serving right now.