How to Decode & Inspect X.509 SSL Certificates and CSRs Without OpenSSL (or Leaking Data to Unknown Servers)

When migrating an internal API gateway to a new Kubernetes cluster, generating a Certificate Signing Request (CSR) is necessary. However, if the CSR does not include the wildcard subdomain in the Subject Alternative Names (SANs) list, the browser will display a NET::ERR_CERT_COMMON_NAME_INVALID error. Two options are available when faced with such an issue: examining the CSR using the OpenSSL CLI or using an online certificate parser. Using the latter option poses significant risks to operational security.

Pasting internal certificates and CSRs into random websites can lead to three types of information leakage. Firstly, the subject alternative names (SANs) contain internal hostnames and infrastructure endpoints, which can reveal the internal network topology. Secondly, the combined certificate chain and private key can be accidentally exposed if a server-side parser runs on the remote site.

Lastly, running server-side parsing on an online utility introduces server-side execution overhead, putting every certificate submitted at risk if the server gets compromised.

Understanding X.509 certificates is essential for safe inspection. These certificates are not plain text but rather an ASN.1 (Abstract Syntax Notation One) data structure serialized into a binary format (DER) and wrapped in Base64 with ASCII boundaries to form a PEM file. To decode DER bytes in-browser using TypeScript, first strip the PEM headers and base64 decode the data.

Then, parse the binary DER stream using a Tag-Length-Value (TLV) approach, where each element in the DER stream is structured as a tag, length, and value.