What is an OID in an X.509 certificate?

An Object Identifier is a globally unique dotted-decimal name, like 2.5.29.17, registered in a hierarchical tree. X.509 uses OIDs to name distinguished-name attributes, extensions, key-usage purposes and algorithms so that different implementations agree on their meaning.

Which OID holds the hostnames a certificate is valid for?

The Subject Alternative Name extension, OID 2.5.29.17, is the authoritative source of valid DNS names, IP addresses and emails. Modern clients ignore the Common Name (2.5.4.3) for hostname matching and use the SAN instead.

What is the difference between keyUsage and extendedKeyUsage?

keyUsage (2.5.29.15) is a low-level bitfield saying what cryptographic operations the key may perform, such as digitalSignature or keyCertSign. extendedKeyUsage (2.5.29.37) names higher-level purposes like serverAuth or clientAuth that constrain where the certificate may be used.

What OID marks a certificate as a CA?

Basic Constraints, OID 2.5.29.19, carries the CA boolean and an optional path-length limit. A CA certificate must have CA:TRUE here and the keyCertSign bit set in keyUsage.

How do I find a certificate's OCSP responder?

The Authority Information Access extension, OID 1.3.6.1.5.5.7.1.1, lists the OCSP responder URL and the CA Issuers URL for fetching the intermediate certificate. Tools display these under AIA in the certificate detail.

X.509 OID Reference — Gera Tools

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

X.509 certificates are described almost entirely in OIDs — dotted-decimal Object Identifiers that name every attribute, extension, key-usage flag and algorithm. When you run openssl x509 -text or inspect a cert in a browser, those numbers are how the format stays unambiguous across implementations. This reference lets you search by OID or by name to decode what each one means.

How it works

OIDs are nodes in a global tree maintained by ISO/ITU and IANA. X.509 draws from a few branches: distinguished-name attributes live under 2.5.4.* (for example 2.5.4.3 is commonName), standard certificate extensions under 2.5.29.* (such as 2.5.29.17 for subjectAltName), and PKIX-defined items like Extended Key Usage purposes under 1.3.6.1.5.5.7.3.*.

Search accepts a dotted OID, a short name, or a keyword. Key-usage bits are listed with their bit position because they are a bitfield rather than separate OIDs.

Tips and examples

The OIDs you will meet most often when reading a TLS certificate:

2.5.4.3            commonName (legacy host name)
2.5.29.17          subjectAltName (authoritative host names)
2.5.29.15          keyUsage (signature / key encipherment bits)
2.5.29.37          extKeyUsage (serverAuth / clientAuth)
2.5.29.19          basicConstraints (CA flag + path length)
1.3.6.1.5.5.7.3.1  id-kp-serverAuth (required for HTTPS)
1.3.6.1.5.5.7.1.1  authorityInfoAccess (OCSP + CA issuers)

A common gotcha: a certificate can present a perfectly correct Common Name yet still fail hostname validation because the name is missing from the SAN (2.5.29.17). Always check the SAN, not the CN. Likewise, a leaf certificate used for a TLS server must list serverAuth in its Extended Key Usage, or strict clients will reject it.