Inspect a CSR or X.509 certificate locally

Distinguish the input formats

A certificate signing request (CSR) contains a subject and public key, signed by the requester. An issued X.509 certificate also contains an issuer, a serial number, validity dates and extensions. A CSR has no issuer-assigned validity period. Both formats may use PEM text around Base64-encoded DER data.

Inspect the fields

Open the X.509 and CSR decoder and paste one complete PEM block. Keep its BEGIN and END labels. Use CERTIFICATE for a certificate or CERTIFICATE REQUEST for a CSR. The browser parser reads the ASN.1 structure locally; you do not need to install OpenSSL for inspection.

-----BEGIN CERTIFICATE REQUEST-----
(base64 DER data)
-----END CERTIFICATE REQUEST-----

Check the result

Compare the subject with the intended identity. For a certificate, review the issuer, validity dates and subject alternative names when present. Inspect the public-key algorithm and size. For a CSR, compare the requested identity and key before submitting it to your certificate authority. Decoding alone does not validate a chain, check revocation, prove ownership or establish that a site is safe.

Keep keys separate

Never paste a PRIVATE KEY PEM block. Public certificates can still reveal internal hostnames or organization details, so use a sample when sharing. Optional AI is separate from local parsing and may send data externally after consent. Test offline availability before relying on a cached installation during an incident.

Normative Verification Checkpoints (RFC 2986 & RFC 5280)

When diagnosing PKI certificates and TLS handshake errors in production, keep these cryptographic rules in mind:

1. Subject Alternative Name (SAN) vs. Common Name (CN): Modern browsers and TLS clients (RFC 5280 & RFC 6125) deprecate reliance on the legacy commonName attribute. If your CSR or certificate does not contain an explicit subjectAltName extension specifying all domains or IP addresses, modern clients will reject the connection with ERR_CERT_COMMON_NAME_INVALID.
2. Proof of Possession (POP): In a valid PKCS#10 CSR (RFC 2986), the private key signs the CertificationRequestInfo structure. The decoder parses this self-signature to verify that the entity requesting the certificate actually possesses the matching private key before submission to a Certificate Authority (CA).
3. Extended Key Usage (EKU) Constraints: Inspect the extKeyUsage OIDs to ensure the certificate specifies serverAuth (1.3.6.1.5.5.7.3.1) for web hosting or clientAuth (1.3.6.1.5.5.7.3.2) for mutual TLS (mTLS) architectures to avoid silent handshake drops.