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 the OID tree is organised
OIDs are nodes in a global tree maintained by ISO/ITU and IANA. Each arc is administered by a different authority, which is why X.509 draws from several branches rather than one tidy block:
2.5.4.*— Distinguished Name attributes (the parts of a Subject or Issuer line).2.5.4.3iscommonName,2.5.4.10isorganizationName.2.5.29.*— Standard certificate extensions. This is where the most-used extensions live: Subject Alternative Name at2.5.29.17, Key Usage at2.5.29.15, Basic Constraints at2.5.29.19.1.3.6.1.5.5.7.3.*— PKIX Extended Key Usage purposes. Server authentication is1.3.6.1.5.5.7.3.1, client authentication1.3.6.1.5.5.7.3.2.1.3.6.1.5.5.7.1.*— PKIX private extensions. The Authority Information Access extension that holds OCSP and CA-Issuers URLs lives at1.3.6.1.5.5.7.1.1.1.2.840.113549.*— RSA Data Security (RSAEncryption, PKCS standards, digest algorithms).
Search accepts a dotted OID, a short name (SAN, keyUsage, serverAuth), or a keyword. Key-usage items are listed with their bit position rather than their own OID, because 2.5.29.15 is a single bitfield extension, not a set of separate identifiers.
Reading a certificate with openssl
openssl x509 -in cert.pem -text -nooutThe output labels extensions and attributes by their short names, but a misconfigured or custom OID may appear only in dotted form. Paste the number here to identify it. A few important sections to look for:
| openssl label | OID | What it means |
|---|---|---|
| Subject Alternative Name | 2.5.29.17 | The DNS names, IPs and emails the cert is actually valid for |
| Key Usage | 2.5.29.15 | Cryptographic operations the key may perform |
| Extended Key Usage | 2.5.29.37 | High-level purposes: serverAuth, clientAuth, codeSigning |
| Basic Constraints | 2.5.29.19 | Whether this is a CA cert, and the path-length cap |
| Authority Info Access | 1.3.6.1.5.5.7.1.1 | OCSP responder URL and CA Issuers download URL |
Common debugging scenarios
Hostname validation fails. Modern browsers and TLS stacks ignore the Common Name (2.5.4.3) for hostname matching and require the name in the Subject Alternative Name (2.5.29.17). A cert can have a perfectly correct CN and still fail validation if the SAN is absent or wrong.
Client rejects a server cert. Check that serverAuth (1.3.6.1.5.5.7.3.1) is present in the Extended Key Usage. Mutual TLS client certs similarly require clientAuth (1.3.6.1.5.5.7.3.2). Strict clients — Go, Java, some modern browser builds — reject certs that lack the appropriate EKU even when the CN and SAN are correct.
Certificate chain won’t build. The CA signing a certificate must have CA:TRUE in its Basic Constraints (2.5.29.19) and the keyCertSign bit set in its Key Usage (2.5.29.15). If a path-length constraint is set, the chain cannot be longer than that value below the CA.
OCSP stapling not working. Look in the Authority Information Access extension (1.3.6.1.5.5.7.1.1) for the OCSP responder URL. If it is absent, the server cannot staple an OCSP response and clients may need to make their own request to the CA’s responder.