What a certificate file contains
An X.509 certificate, specified in RFC 5280, is an ASN.1 structure encoded in DER, a strict binary format. It has three parts: the to-be-signed block with the names, dates, public key and extensions; the signature algorithm; and the issuer's signature over that block. PEM is the same DER bytes in Base64 between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.
The decoder accepts either form. Pasted text is searched for PEM blocks labelled CERTIFICATE, CERTIFICATE REQUEST or PKCS7, and an uploaded binary file is identified from its structure. Base64 pasted without the BEGIN and END lines is decoded as well. File extensions are ignored, since .crt and .cer are used for both text and binary files.
The Details rows, one by one
Subject and Issuer are distinguished names printed as attribute pairs, for example C=US, O=Example Inc, CN=www.example.com. Valid from and Valid to are the notBefore and notAfter times. Public key gives the algorithm and size: RSA with the modulus length in bits, or EC with its curve (P-256, P-384 or P-521). Signature is the algorithm the issuer signed with, such as SHA-256 with RSA or ECDSA with SHA-384.
Serial number is the issuer-assigned number in hexadecimal, the value revocation lists use to identify a certificate. The fingerprints are SHA-256 and SHA-1 hashes of the whole DER encoding, computed locally. Compare the SHA-256 value with the one a server or vendor publishes to confirm you hold the same certificate.
Extensions that decide how a certificate may be used
Each extension is listed by name with its decoded value, plus a critical pill when the certificate marks it critical, meaning software that does not understand the extension must reject the certificate. Extensions without a dedicated parser are listed by name or OID with their size in bytes.
A server certificate needs TLS Web Server Authentication in Extended Key Usage and CA: FALSE in Basic Constraints. When a chain is incomplete, the CA Issuers URL points to the missing intermediate. Signed Certificate Timestamps are reported as embedded Certificate Transparency proofs, without the individual logs.
- Key Usage: operations such as Digital Signature or Certificate Sign
- Extended Key Usage: purposes such as TLS Web Server Authentication
- Basic Constraints: CA: TRUE or FALSE, plus any path length
- Authority Information Access: the OCSP and CA Issuers URLs
- CRL Distribution Points: where the revocation list is published
- Certificate Policies: DV, OV, IV or EV for known policy OIDs
Checking a chain or a CSR before you install
For a chain, paste the leaf and its intermediates together. The cards follow the order of the file. Servers send the leaf first, so the first card should be your own certificate and each Issuer should equal the Subject of the next card. A root at the end is optional. To rebuild a bundle in another format, use the certificate converter.
A CSR decodes to a shorter card: subject, public key, signature algorithm and the requested names from its extension request. Read it before you submit, because the CA issues what the request says. If Requested names is empty the CSR has no SAN extension, and most CAs then add the common name on their own. Requests made with the CSR generator always list the common name as a SAN.
What decoding does not prove
The tool parses. It does not validate. It does not verify signatures, build a path to a trusted root, or ask an OCSP responder or CRL whether the certificate was revoked. The Self-signed pill comes from comparing the issuer and subject names, and Valid means only that today falls between the two dates on your own clock. A certificate that decodes cleanly can still be refused by a client.
It also reads a file, not a live server. To see the certificate a mail server presents during STARTTLS, run the SMTP test. A pasted private key triggers a warning and is not processed. A PFX or P12 file is recognised and answered with the OpenSSL command that extracts the certificate, because that container is password protected.