Read an SSL certificate

Paste the PEM or load the file and read in plain words when it expires, which names it covers, what key it uses and whether the chain is in the right order. It works for certificate signing requests (CSR) and .p7b files too, and the certificate never leaves your browser.

Or tap here or drop the file: .crt, .cer, .pem, .der, .csr, .p7b, .ca-bundle
The certificate is read here, inside your browser: it is not uploaded anywhere and the page does not connect to any site.

When you need to read a certificate

The most common case is also the most trivial one: when it expires. Your supplier sent you the file of the new certificate, or you have to renew the old one, and the hosting panel does not tell you. Here the first number you see is the days left, and if the certificate has already expired or is not valid yet you see it before everything else, in red or in yellow.

The other real cases are three. The browser says «certificate not valid» and you want to know whether it is a problem of names (the certificate does not cover that subdomain) or of chain (a piece is missing on the server). You have to send a certificate signing request (CSR) to the authority and you want to check that the right names are inside before paying. Or a .cer or .p7b file reaches you by email and you want to know what it is before installing it.

The page takes pasted PEM (several certificates in a row too), .crt, .cer, .pem and .der files, CSRs and .p7b files, and recognises the type from what is inside, not from the extension.

Covered names: the common name no longer counts

The names a certificate is valid for sit in the subject alternative names (SAN), and they are the only thing today's browsers look at: Chrome stopped reading the common name, the CN, in 2017, and Safari in 2019. A certificate with the right name only in the CN gives an error today.

The wildcard works for one level only. A certificate for *.example.com covers www.example.com and shop.example.com, but not example.com on its own (it needs one more name) and not a.b.example.com either (that would need *.b.example.com). Type the name in the «Name to check» field and the answer is yes or no, with the certificate name that covers it.

The names can include IP addresses, typical of the NAS or the home router: there the certificate is valid only for that exact address, and a domain name pointing to the same address is not enough. To reason about addresses and networks there is Subnet calculator.

The chain, and why the order matters

A site does not send one certificate only: it sends its own, issued by an intermediate, which in turn was issued by a root that the browser already knows. The link is read inside the certificates: the issuer of each one must be the subject of the next. If you paste the whole chain, the page checks the links one by one.

When the order is wrong you get the chain already reordered, ready to copy into the file the server sends (the one many panels call fullchain). The most common fault, though, is another one: the missing intermediate. Some browsers go and fetch it by themselves and the site seems to work, while curl, many phone apps and many programs give an error. If you paste what the server sends and there is nothing after the site's certificate, that is the problem. And if you built the file by joining two files with cat, check that there is a line break between an END line and the next BEGIN: stuck together, OpenSSL finds no certificate at all, and the page flags it.

There is a subtler case too: an intermediate with the right name and the wrong key. It happens when an authority renews its key and the old file is left on the server. The names match, but the key identifiers do not, and the page flags it. In .p7b files, on the other hand, the order does not exist, because the certificates sit in a set: the page shows them already lined up from the site to the root.

Dates: time zone, days and maximum lifetime

The dates inside a certificate are always in universal time (UTC), and that is how you find them written here. In most of Europe that is one hour ahead in winter and two in summer, so a certificate that expires at 23:30 UTC on the 3rd has already expired in Rome on the 4th. The days left are whole 24-hour days, counted from the moment you read.

Then there is the lifetime. Since September 2020 a public site certificate cannot last more than 398 days, and the CA/Browser Forum rules are shortening it: 200 days for those issued from 15 March 2026, 100 from 15 March 2027, 47 from 15 March 2029. If a site certificate lasts longer than was allowed on the day it was issued, the page flags it: if it comes from a public authority the browser refuses it, if it comes from an authority internal to a company the rule does not apply.

A detail that trips up home-made readers: until 2049 the year is written with two digits only, and «50» means 1950, not 2050, as the standard says (RFC 5280).

Key, signature and fingerprints

The key tells you how strong the certificate is. An RSA key of 2048 bits is the accepted minimum, 3072 or 4096 are slower and stronger; elliptic-curve keys P-256 and P-384 are shorter for the same security. Ed25519 exists in certificates, but browsers do not accept it for sites yet. Below 2048 bits and with SHA-1 or MD5 signatures the page shows a warning, because those are exactly the cases where a browser refuses.

The fingerprints SHA-256 and SHA-1 are the digest of the whole certificate, computed here with the browser's cryptographic functions: they are used to compare two certificates without reading them, for instance over the phone with whoever runs the server, and they are the same number that Windows, macOS and OpenSSL show. The SHA-1 one is only a label here and not a signature, and it is what Windows calls the «thumbprint». For the fingerprint of any file, not a certificate, there is File checksum.

The serial number is what the authority asks you for to revoke a certificate. The OCSP and CRL lines say where the browser asks whether it has been revoked: the page shows them, but does not connect to them.

Names with accents, written in four ways

Inside a certificate text can be encoded in different ways, and a hasty reader treats them all as UTF-8. Here each one is read for what it is: UTF8String as UTF-8, BMPString as UTF-16, the old UniversalString as UTF-32. The hard case is the T61String, which in real certificates holds UTF-8 sometimes and Latin-1 other times: the page tries the first and, if the bytes are not UTF-8, uses the second, which is what OpenSSL does. That way «Società» stays «Società» instead of turning into a row of symbols, and when Latin-1 was needed the page says so.

What it does not do, said plainly

It does not check the signature and does not say whether the certificate can be trusted: it shows what is written. To know whether a site is set up well you need a check that connects to the server, and a web page cannot do that, because browsers do not give another site's certificate to a page's code. To get it, click the padlock next to the address and export the certificate, or use openssl s_client -connect example.com:443 -showcerts and paste here what comes out.

It does not open .pfx and .p12 files: they contain the private key and are encrypted with a password. And if you paste a private key together with the certificate, the page does not read it and warns you, because a private key must never be pasted anywhere. To read an access token, which is another thing even if it looks similar, there is JWT decoder.