Parse ASN.1

One line per TLV: the tag name, whether it is constructed or primitive, the content length in bytes, and the offset in hex where the tag byte sits. Children are indented under their parent. Universal tags are named, so you see SEQUENCE, SET, INTEGER, BIT STRING, OCTET STRING, OBJECT IDENTIFIER, UTF8String, PrintableString, IA5String, UTCTime and the rest. Context, application and private tags print as their class and number, for example [context 0].

By type. An OBJECT IDENTIFIER is decoded to dotted-decimal and named when it is in the built-in table of common X.509 and PKCS identifiers. An INTEGER of 6 bytes or fewer prints in decimal and longer ones print in hex. BOOLEAN prints TRUE or FALSE. Text types are decoded as strict UTF-8 and quoted, falling back to hex if that fails. Everything else prints as hex, truncated to the first 64 bytes with the true length shown.

It parses DER, not BER, and it says what went wrong inside the message "not valid DER ASN.1". The specific causes it names are indefinite-length BER encoding, which is not supported, a length field that runs past the end of the buffer, a declared length at a given offset that runs past the end, and nesting deeper than 32 levels, which it stops on rather than recursing through non-ASN.1 input.

No, it needs the raw DER bytes. PEM is base64 inside BEGIN and END lines, so the parser sees text, not a tag byte. Convert it first: PEM to Hex gives you the DER payload as hex, From hexdump turns that back into bytes, and those bytes parse here. For certificates specifically, Parse X.509 certificate reads the fields directly.

Because it parses the first top-level structure and stops. A file holding two concatenated DER blobs shows only the first, and trailing bytes after it are ignored without a warning. Compare the length reported on the root line plus its header against the file size to see whether anything was left over, and cut the remainder out with Drop bytes to parse it separately.

It still prints in dotted-decimal form, with no name after it. The built-in table covers the identifiers seen constantly in X.509 and PKCS structures, such as rsaEncryption, sha256WithRSAEncryption, ecPublicKey, commonName and the standard certificate extensions. It is not the full IANA registry, so an unrecognised OID means unrecognised here, not invalid.