ASN.1 OID Lookup

Look up well-known ASN.1 / X.509 object identifiers.

Open tool

Overview

The ASN.1 OID lookup resolves dotted object identifiers like 1.3.6.1.5.5.7.1.1 to their human-readable names from the registered tree maintained by ITU-T, IETF, and other bodies. Paste an OID from an X.509 certificate, an SNMP MIB, or an LDAP schema and see what it actually stands for.

Security engineers and PKI operators reach for an ASN.1 OID decoder when reading certificate extensions, debugging SAML assertions, or building tooling that emits X.509 attributes. It's faster than hand-walking the IANA registry every time you spot an unfamiliar number.

How it works

OIDs are hierarchical: each arc under the root names a sub-authority, and the leaf identifies a specific attribute, algorithm, or extension. The lookup carries a bundled dictionary of well-known OIDs covering X.509 (2.5.4.* distinguished name attributes), PKIX extensions (1.3.6.1.5.5.7.*), PKCS standards (1.2.840.113549.*), and common signature algorithms (1.2.840.10045.* ECDSA, 1.2.840.113549.1.1.* RSA).

Matching is longest-prefix: if the exact OID isn't in the dictionary, the tool returns the closest registered ancestor along with a note describing the remaining sub-arcs.

Examples

Input:  2.5.4.3
Output: id-at-commonName (X.520 commonName attribute)
Input:  1.2.840.113549.1.1.11
Output: sha256WithRSAEncryption (PKCS#1 signature algorithm)
Input:  1.3.6.1.5.5.7.3.1
Output: id-kp-serverAuth (TLS WWW server authentication EKU)

FAQ

Does it cover SNMP enterprise OIDs?

The bundled dictionary focuses on cryptography and X.509, which is what most users need. SNMP enterprise numbers under 1.3.6.1.4.1.* are recognised at the enterprise prefix; specific vendor MIB leaves are not exhaustively included.

Can I look up a name and get the OID back?

Yes. The lookup is bidirectional, so typing commonName or sha256WithRSAEncryption returns the matching dotted identifier.

Why does my OID resolve to a parent instead of the exact name?

Some OIDs are vendor-specific and not in the public registry. The longest-prefix match still tells you which authority owns the namespace, which is usually enough to track down vendor docs.

Try ASN.1 OID Lookup

An unhandled error has occurred. Reload ×