Explorador de ASN.1 online: decodificador de DER y BER

ASN.1, DER and BER in one paragraph

Almost every object in public-key infrastructure is written in ASN.1: X.509 certificates, certificate signing requests, revocation lists, OCSP messages, PKCS #8 and PKCS #12 key files, CMS signatures. ASN.1 itself only describes structure — a certificate is a SEQUENCE of a to-be-signed part, an algorithm identifier and a BIT STRING. The bytes come from an encoding rule set defined in ITU-T X.690: BER (Basic Encoding Rules), and its strict subset DER (Distinguished Encoding Rules). Both write every value as a tag, a length and the content — a TLV. BER allows several spellings of the same value; DER allows exactly one, which is why signatures are computed over DER: the verifier must hash exactly the bytes the signer hashed.

What the explorer does with your input

The explorer accepts the forms these objects travel in. A PEM block (RFC 7468) is base64 between -----BEGIN …----- lines; when the paste holds several blocks — a chain, or a key next to a certificate — you pick which one to explore. Bare base64, base64url and hex dumps (with spaces, colons or a 0x prefix) work too, and a binary .der, .cer or .p7b file can be dropped onto the page or chosen with the file picker. The file is read with the browser's File API; it is never uploaded.

The bytes are then parsed with @lapo/asn1js, the decoder behind the well-known lapo.it ASN.1 viewer. It reads full BER — indefinite lengths, segmented strings — and, importantly, looks inside OCTET STRING and BIT STRING values that wrap further DER, which is how certificate extensions and public keys are nested. Those encapsulated elements appear as children in the tree.

For every element you see the byte offset, the header length, the content length, the tag class and number, and the decoded value: integers in decimal and hex with their bit length, object identifiers with their dotted form and name, strings in their declared type, times converted to UTC. Selecting an element highlights its bytes in the hex dump — tag and length octets in one colour, content in another — and clicking a byte selects the deepest element that covers it. Each element can be copied as hex or base64, which is handy when you need just the public key or just one extension.

Field names from the RFC modules

A bare TLV tree says "SEQUENCE, INTEGER, SEQUENCE…". The explorer also tries the ASN.1 modules of the common standards against the whole structure — the certificate and CRL modules of RFC 5280, PKCS #10 (RFC 2986), PKCS #8, CMS (RFC 5652) and a few more. When one fits well, elements get their field names: tbsCertificate, subjectPublicKeyInfo, revokedCertificates. The summary says which type matched, and which kind of object the bytes look like even when no module matched.

The DER checks

Because the parser accepts BER, the explorer can tell you precisely where an encoding departs from DER — the usual reason one library accepts a file and another throws "header too long" or "tags don't match". Each element is checked against the canonical-encoding rules of X.690 §10 and §11:

• lengths written in the long form when the short form fits, or with leading zero octets;
• indefinite lengths and constructed (segmented) strings, which are BER-only;
• tag numbers below 31 written in the multi-byte form;
• INTEGERs with redundant leading 00 or FF octets, BOOLEAN TRUE written as anything but FF;
• BIT STRINGs whose unused bits are not zero, NULLs with content, malformed object identifiers;
• times that are not in the DER form (UTC "Z", with seconds, no trailing zeros in fractions);
• SET OF members that are not sorted by their encoding, and strings with characters their type does not allow.

Problems are marked on the element in the tree and listed in its details. BER is legitimate in CMS and PKCS #12 — Java and Windows write it routinely — but certificates, CRLs and keys must be DER, and the summary says which one you have. The structural limits are deliberate too: more than 256 levels of nesting or 100,000 elements is reported as an error rather than parsed, since inputs like that are corrupt or built to exhaust parsers.

What runs where

Everything above happens in this page. Parsing, the DER checks, OID naming and the hex dump are JavaScript running in your browser; the page makes no request with your data. If you paste a private key, it is decoded like anything else and flagged as private material — still, a key that has been pasted into other websites should be treated as exposed. Share links carry the input in the URL fragment, which browsers never send to a server, and they refuse private keys and PKCS #12 files outright: a link with a key in it would be the key, published.

Where to go next

To change a structure rather than read it, open the DER text editor: it converts DER to an editable text form and back, byte for byte. Certificates have a dedicated certificate decoder, and CSRs, CRLs and OCSP messages have their own decoders on the PKI hub. And if a library insists on "PEM" while you hold "DER": they are the same bytes — PEM is DER in base64 between two header lines, so the explorer shows both identically.