Certificate & CSR Decoder

A certificate or CSR is never "written" the way source code is. The real content is DER (Distinguished Encoding Rules), a compact binary TLV (tag-length-value) encoding defined by ASN.1 - every field is a typed, length-prefixed byte sequence nested inside larger sequences. PEM (RFC 7468) is just that same DER, base64-encoded and wrapped between a `-----BEGIN ...-----` and `-----END ...-----` line so it survives being pasted into email, a config file, or a terminal.

The label between the BEGIN/END markers tells a decoder what is inside before it reads a single byte of content: `CERTIFICATE` wraps a DER-encoded X.509 certificate, `CERTIFICATE REQUEST` (or the older `NEW CERTIFICATE REQUEST`) wraps a PKCS#10 `CertificationRequest`, and `PRIVATE KEY` / `RSA PRIVATE KEY` wrap key material that a certificate decoder should never need and should not accept as its subject.

Because DER is strict TLV, a decoder can walk it without guessing: read a tag, read its length, read exactly that many content bytes, then move to the next sibling. Malformed input - a length that claims more bytes than remain, or nesting deeper than any real certificate ever goes - is a structural defect a decoder can reject outright rather than trying to interpret.

• PEM = base64(DER) + BEGIN/END fence naming the content type - the encoding is cosmetic, not cryptographic
• A certificate and a CSR are structurally different objects: a certificate is issued and signed by a CA, a CSR is unsigned-by-a-CA and only self-signed to prove key possession
• Multiple PEM blocks can appear in one file (a leaf certificate followed by intermediates) - a decoder reading only the first block silently ignores the rest
• DER is definite-length only in practice for certificates and CSRs; the indefinite-length form exists in BER but is never used by CAs or CSR-generating tools

A CSR (Certificate Signing Request, PKCS#10, RFC 2986) is what an applicant generates and sends to a CA: a subject name, a public key, and a self-signature over both - proof the requester holds the private key, nothing more. A CSR carries no validity dates, no issuer, and no CA-assigned serial number, because none of that exists yet. Any extensions the applicant wants on the eventual certificate (most commonly Subject Alternative Names) travel inside the CSR as an `extensionRequest` attribute (OID 1.2.840.113549.1.9.14) - a request, not a guarantee; the issuing CA decides what actually makes it into the certificate.

A certificate (X.509v3, RFC 5280) is what the CA hands back: the same subject and public key, now bound together by the CA's own signature, plus fields only a CA can add - an issuer name, a serial number unique to that CA, a validity window (notBefore/notAfter), and the extensions the CA actually approved and signed over. The CSR's self-signature and the certificate's CA-issued signature answer two different questions: "does the requester hold this private key" versus "did a CA vouch for this subject/key pair".

This is why a decoder cannot treat the two as variants of one format. A CSR has no issuer to display and no expiry to check; a certificate has no signature to "verify" against its own key, because it was never self-signed in the first place (except for root CA certificates, which are a special case).

Subject and issuer are both X.501 Distinguished Names - an ordered sequence of relative distinguished names (RDNs), each an attribute-type/value pair such as `CN` (Common Name), `O` (Organization), `OU` (Organizational Unit), or `C` (Country). The subject identifies who the certificate is issued to; the issuer identifies the CA that signed it. For a self-signed root, subject and issuer are identical.

validFrom and validTo mark the certificate's validity window (the notBefore/notAfter fields in RFC 5280) - outside that window the certificate is invalid regardless of anything else about it, with no grace period on either edge. Serial number is an integer the issuing CA assigns, unique within that CA's namespace; it is what a revocation check (CRL or OCSP) references, not the certificate's content hash.

The SHA-256 fingerprint is a hash of the entire DER-encoded certificate - change one bit anywhere (a re-signed copy, a different serial, a corrupted download) and the fingerprint changes completely. It is how you confirm two files are byte-for-byte the same certificate without diffing raw bytes. Subject Alternative Name (SAN) is the extension (OID 2.5.29.17) that modern clients actually match against a hostname - DNS names, IP addresses, email addresses, and URIs can all appear here, and a certificate can list several of any type.

The public key section reports the algorithm (RSA or EC) and size - modulus length in bits for RSA, named-curve bit strength for EC (P-256 is 256-bit, P-384 is 384-bit). Key Usage restricts what the key is cryptographically permitted to do (digitalSignature, keyEncipherment, keyCertSign, and so on); the CA basic-constraints flag reports whether the certificate is itself allowed to sign other certificates. Authority Information Access carries the OCSP responder URL(s) (for live revocation status) and CA Issuers URL(s) (for fetching the issuing CA's own certificate, used when a chain is incomplete).

A decoded CSR shows the same subject-name breakdown as a certificate (CN, O, OU, C, and so on, walked out of the same RDN structure) and the same public key algorithm/size reporting - but stops there for anything CA-issued. There is no issuer, no validity window, and no CA-assigned serial, because a CSR is a request, not a credential.

Requested Subject Alternative Names come from the CSR's `extensionRequest` attribute, not a signed extension - a CA can honor them, add different ones, or drop them entirely when it issues the certificate. Treat the SAN list on a CSR as "what was asked for," never as "what the final certificate will contain."

Signature validity on a CSR means one specific, narrow thing: the self-signature over the CSR's own `CertificationRequestInfo` (subject + public key + attributes) checks out against the CSR's own embedded public key. That confirms the requester who generated the CSR controls the corresponding private key. It says nothing about whether the subject name is legitimate, whether the requester actually owns the domains listed, or whether any CA has agreed to issue anything - those checks happen entirely on the CA's side, after submission.

Decoding is entirely local to the bytes you paste - there is no hostname to resolve, no port to connect to, and no live server involved at any point. That makes it the right tool for a CSR before it is ever sent anywhere, a certificate saved from a config file or received by email, or a chain file being assembled for a server, all of which have no live endpoint to check against yet.

It answers a different question than checking a certificate as served by a live host over TLS: decoding tells you what a specific file contains; a live check additionally tells you what a server actually presents on the wire right now, whether the chain it sends is complete, and how the negotiated TLS session behaves - none of which exist independent of an active connection.