B.3. Standard X.509 v3 Certificate Extension Reference

An X.509 v3 certificate contains an extension field that permits any number of additional fields to be added to the certificate. Certificate extensions provide a way of adding information such as alternative subject names and usage restrictions to certificates. Older Netscape servers, such as Red Hat Directory Server and Red Hat Certificate System, that were developed before PKIX part 1 standards were defined require Netscape-specific extensions.
The following is an example of the section of a certificate containing X.509 v3 extensions. The Certificate System can display certificates in readable pretty-print format, as shown here. As in this example, certificate extensions appear in sequence and only one instance of a particular extension may appear per certificate; for example, a certificate may contain only one subject key identifier extension. Certificates that support these extensions have the version 0x2 (which corresponds to version 3).

Example B.3. Sample Pretty-Print Certificate Extensions

  Version:  v3
  Serial Number: 0x1
  Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
  Issuer: CN=Certificate Manager,OU=netscape,O=ExampleCorp,L=MV,ST=CA,C=US
    Not Before: Friday, February 21, 2005 12:00:00 AM PST America/Los_Angeles
    Not  After: Monday, February 21, 2007 12:00:00 AM PST America/Los_Angeles
  Subject: CN=Certificate Manager,OU=netscape,O=ExampleCorp,L=MV,ST=CA,C=US
  Subject Public Key Info: 
    Algorithm: RSA - 1.2.840.113549.1.1.1
    Public Key: 
      Exponent: 65537
      Public Key Modulus: (2048 bits) :
    Identifier: Netscape Certificate Type - 2.16.840.1.113730.1.1
      Critical: no 
      Certificate Usage: 
        SSL CA 
        Secure Email CA 
        ObjectSigning CA 
    Identifier: Basic Constraints -
      Critical: yes 
      Is CA: yes 
      Path Length Constraint: UNLIMITED
    Identifier: Subject Key Identifier -
      Critical: no 
      Key Identifier: 
    Identifier: Authority Key Identifier -
      Critical: no 
      Key Identifier: 
    Identifier: Key Usage: -
      Critical: yes 
      Key Usage: 
        Digital Signature 
        Key CertSign 
        Crl Sign 
    Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5

An object identifier (OID) is a string of numbers identifying a unique object, such as a certificate extension or a company's certificate practice statement. The Certificate System comes with a set of extension-specific profile plug-in modules which enable X.509 certificate extensions to be added to the certificates the server issues. Some of the extensions contain fields for specifying OIDs.
The PKIX standard recommends that all objects, such as extensions and statements, that are used in certificates be included in the form of an OID. This promotes interoperability between organizations on a shared network. If certificates will be issued that will be used on shared networks, register the OID prefixes with the appropriate registration authority.
OIDs are controlled by the International Standards Organization (ISO) registration authority. In some cases, this authority is delegated by ISO to regional registration authorities. In the United States, the American National Standards Institute (ANSI) manages this registration.
Using an OID registered to another organization or failing to register an OID may carry legal consequences, depending the situation. Registration may be subject to fees. For more information, contact the appropriate registration authority.
To define or assign OIDs for custom objects, know the company's arc, an OID for a private enterprise. If the company does not have an arc, it needs to get one. The http://www.alvestrand.no/objectid/ has more information on registering and using OIDs.
For example, the Netscape-defined OID for an extension named Netscape Certificate Comment is 2.16.840.1.113730.1.13. The OID assigned to this extension is hierarchical and includes the former Netscape company arc, 2.16.840.1. The OID definition entry is http://www.alvestrand.no/objectid/2.16.840.1.113730.1.13.html.
If an OID extension exists in a certificate and is marked critical, the application validating the certificate must be able to interpret the extension, including any optional qualifiers, or it must reject the certificate. Since it is unlikely that all applications will be able to interpret a company's custom extensions embedded in the form of OIDs, the PKIX standard recommends that the extension be always marked noncritical.
This section summarizes the extension types defined as part of the Internet X.509 version 3 standard and indicates which types are recommended by the PKIX working group.
This reference summarizes important information about each certificate. For complete details, see both the X.509 v3 standard, available from the ITU, and Internet X.509 Public Key Infrastructure - Certificate and CRL Profile (RFC 3280), available at RFC 3280. The descriptions of extensions reference the RFC and section number of the standard draft that discusses the extension; the object identifier (OID) for each extension is also provided.
Each extension in a certificate can be designated as critical or noncritical. A certificate-using system, such as a web browser, must reject the certificate if it encounters a critical extension it does not recognize; however, a noncritical extension can be ignored if it is not recognized.

B.3.1. authorityInfoAccess

The Authority Information Access extension indicates how and where to access information about the issuer of the certificate. The extension contains an accessMethod and an accessLocation field. accessMethod specifies by OID the type and format of information about the issuer named in accessLocation.
PKIX Part 1 defines one accessMethod (id-ad-caIssuers) to get a list of CAs that have issued certificates higher in the CA chain than the issuer of the certificate using the extension. The accessLocation field then typically contains a URL indicating the location and protocol (LDAP, HTTP, or FTP) used to retrieve the list.
The Online Certificate Status Protocol (RFC 2560), available at RFC 2560, defines an accessMethod (id-ad-ocsp) for using OCSP to verify certificates. The accessLocation field then contains a URL indicating the location and protocol used to access an OCSP responder that can validate the certificate.
This extension must be noncritical.

B.3.2. authorityKeyIdentifier

The Authority Key Identifier extension identifies the public key corresponding to the private key used to sign a certificate. This extension is useful when an issuer has multiple signing keys, such as when a CA certificate is renewed.
The extension consists of one or both of the following:
  • An explicit key identifier, set in the keyIdentifier field
  • An issuer, set in the authorityCertIssuer field, and serial number, set in the authorityCertSerialNumber field, identifying a certificate
If the keyIdentifier field exists, it is used to select the certificate with a matching subjectKeyIdentifier extension. If the authorityCertIssuer and authorityCertSerialNumber fields are present, then they are used to identify the correct certificate by issuer and serialNumber.
If this extension is not present, then the issuer name alone is used to identify the issuer certificate.
PKIX Part 1 requires this extension for all certificates except self-signed root CA certificates. Where a key identifier has not been established, PKIX recommends that the authorityCertIssuer and authorityCertSerialNumber fields be specified. These fields permit construction of a complete certificate chain by matching the SubjectName and CertificateSerialNumber fields in the issuer's certificate against the authortiyCertIssuer and authorityCertSerialNumber in the Authority Key Identifier extension of the subject certificate.
This extension is always noncritical and is always evaluated.

B.3.3. basicConstraints

This extension is used during the certificate chain verification process to identify CA certificates and to apply certificate chain path length constraints. The cA component should be set to true for all CA certificates. PKIX recommends that this extension should not appear in end-entity certificates.
If the pathLenConstraint component is present, its value must be greater than the number of CA certificates that have been processed so far, starting with the end-entity certificate and moving up the chain. If pathLenConstraint is omitted, then all of the higher level CA certificates in the chain must not include this component when the extension is present.
PKIX Part 1 requires that this extension be marked critical. This extension is evaluated regardless of its criticality.

B.3.4. certificatePoliciesExt

The Certificate Policies extension defines one or more policies, each of which consists of an OID and optional qualifiers. The extension can include a URI to the issuer's Certificate Practice Statement or can embed issuer information, such as a user notice in text form. This information can be used by certificate-enabled applications.
If this extension is present, PKIX Part 1 recommends that policies be identified with an OID only, or, if necessary, only certain recommended qualifiers.
This extension may be critical or noncritical.

B.3.5. CRLDistributionPoints

This extension defines how CRL information is obtained. It should be used if the system is configured to use CRL issuing points.
If the extension contains a DistributionPointName with a type set to URI, the URI is assumed to be a pointer to the current CRL for the specified revocation reasons and will be issued by the named cRLIssuer. The expected values for the URI are those defined for the Subject Alternative Name extension. If the distributionPoint omits reasons, the CRL must include revocations for all reasons. If the distributionPoint omits cRLIssuer, the CRL must be issued by the CA that issued the certificate.
PKIX recommends that this extension be supported by CAs and applications.
PKIX recommends that this extension be marked noncritical and that it be supported for all certificates.

B.3.6. extKeyUsage

The Extended Key Usage extension indicates the purposes for which the certified public key may be used. These purposes may be in addition to or in place of the basic purposes indicated in the Key Usage extension.
The Extended Key Usage extension must include OCSP Signing in an OCSP responder's certificate unless the CA signing key that signed the certificates validated by the responder is also the OCSP signing key. The OCSP responder's certificate must be issued directly by the CA that signs certificates the responder will validate.
The Key Usage, Extended Key Usage, and Basic Constraints extensions act together to define the purposes for which the certificate is intended to be used. Applications can use these extensions to disallow the use of a certificate in inappropriate contexts.
Table B.29, “PKIX Extended Key Usage Extension Uses” lists the uses defined by PKIX for this extension, and Table B.30, “Private Extended Key Usage Extension Uses” lists uses privately defined by Netscape.
If this extension is marked critical, the certificate must be used for one of the indicated purposes only. If it is not marked critical, it is treated as an advisory field that may be used to identify keys but does not restrict the use of the certificate to the indicated purposes.

Table B.29. PKIX Extended Key Usage Extension Uses

Server authentication
Client authentication
Code signing
OCSP Signing[a]
[a] OCSP Signing is not defined in PKIX Part 1, but in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP.

Table B.30. Private Extended Key Usage Extension Uses

Certificate trust list signing
Microsoft Server Gated Crypto (SGC)
Microsoft Encrypted File System
Netscape SGC 2.16.840.1.113730.4.1

B.3.7. issuerAltName Extension

The Issuer Alternative Name extension is used to associate Internet-style identities with the certificate issuer. Names must use the forms defined for the Subject Alternative Name extension.
PKIX Part 1 recommends that this extension be marked noncritical.

B.3.8. keyUsage

The Key Usage extension defines the purpose of the key contained in the certificate. The Key Usage, Extended Key Usage, and Basic Constraints extensions act together to specify the purposes for which a certificate can be used.
If this extension is included at all, set the bits as follows:
  • digitalSignature (0) for SSL client certificates, S/MIME signing certificates, and object-signing certificates.
  • nonRepudiation (1) for some S/MIME signing certificates and object-signing certificates.


    Use of this bit is controversial. Carefully consider the legal consequences of its use before setting it for any certificate.
  • keyEncipherment (2) for SSL server certificates and S/MIME encryption certificates.
  • dataEncipherment (3) when the subject's public key is used to encrypt user data instead of key material.
  • keyAgreement (4) when the subject's public key is used for key agreement.
  • keyCertSign (5) for all CA signing certificates.
  • cRLSign (6) for CA signing certificates that are used to sign CRLs.
  • encipherOnly (7) if the public key is used only for enciphering data. If this bit is set, keyAgreement should also be set.
  • decipherOnly (8) if the public key is used only for deciphering data. If this bit is set, keyAgreement should also be set.
Table B.31, “Certificate Uses and Corresponding Key Usage Bits” summarizes the guidelines for typical certificate uses.
If the keyUsage extension is present and marked critical, then it is used to enforce the usage of the certificate and key. The extension is used to limit the usage of a key; if the extension is not present or not critical, all types of usage are allowed.
If the keyUsage extension is present, critical or not, it is used to select from multiple certificates for a given operation. For example, it is used to distinguish separate signing and encryption certificates for users who have separate certificates and key pairs for operations.
This extension may be critical or noncritical. PKIX Part 1 recommends that it should be marked critical if it is used.

Table B.31. Certificate Uses and Corresponding Key Usage Bits

Purpose of Certificate Required Key Usage Bit
CA Signing
  • keyCertSign
  • cRLSign
SSL Client digitalSignature
SSL Server keyEncipherment
S/MIME Signing digitalSignature
S/MIME Encryption keyEncipherment
Certificate Signing keyCertSign
Object Signing digitalSignature

B.3.9. nameConstraints

This extension, which can used in CA certificates only, defines a name space within which all subject names in subsequent certificates in a certification path must be located.
PKIX Part 1 requires that this extension be marked critical.

B.3.10. OCSPNocheck

The extension is meant to be included in an OCSP signing certificate. The extension tells an OCSP client that the signing certificate can be trusted without querying the OCSP responder (since the reply would again be signed by the OCSP responder, and the client would again request the validity status of the signing certificate). This extension is null-valued; its meaning is determined by its presence or absence.
Since the presence of this extension in a certificate will cause OCSP clients to trust responses signed with that certificate, use of this extension should be managed carefully. If the OCSP signing key is compromised, the entire process of validating certificates in the PKI will be compromised for the duration of the validity period of the certificate. Therefore, certificates using OCSPNocheck should be issued with short lifetimes and be renewed frequently.
This extension should be noncritical.

B.3.11. policyConstraints

This extension, which is for CA certificates only, constrains path validation in two ways. It can be used to prohibit policy mapping or to require that each certificate in a path contain an acceptable policy identifier.
PKIX requires that, if present, this extension must never consist of a null sequence. At least one of the two available fields must be present.
This extension may be critical or noncritical.

B.3.12. policyMappings

The Policy Mappings extension is used in CA certificates only. It lists one or more pairs of OIDs used to indicate that the corresponding policies of one CA are equivalent to policies of another CA. It may be useful in the context of cross-pair certificates.
This extension may be supported by CAs and applications.
This extension must be noncritical.

B.3.13. privateKeyUsagePeriod

The Private Key Usage Period extension allows the certificate issuer to specify a different validity period for the private key than for the certificate itself. This extension is intended for use with digital signature keys.


PKIX Part 1 recommends against the use of this extension. CAs conforming to PKIX Part 1 must not generate certificates with this extension.

B.3.14. subjectAltName

The Subject Alternative Name extension includes one or more alternative (non-X.500) names for the identity bound by the CA to the certified public key. It may be used in addition to the certificate's subject name or as a replacement for it. Defined name forms include Internet electronic mail address (SMTP, as defined in RFC-822), DNS name, IP address (both IPv4 and IPv6), and uniform resource identifier (URI).
PKIX requires this extension for entities identified by name forms other than the X.500 distinguished name (DN) used in the subject field. PKIX Part 1 describes additional rules for the relationship between this extension and the subject field.
Email addresses may be provided in the Subject Alternative Name extension, the certificate subject name field, or both. If the email address is part of the subject name, it must be in the form of the EmailAddress attribute defined by PKCS #9. Software that supports S/MIME must be able to read an email address from either the Subject Alternative Name extension or from the subject name field.
If the certificate's subject field is empty, this extension must be marked critical.

B.3.15. subjectDirectoryAttributes

The Subject Directory Attributes extension conveys any desired directory attribute values for the subject of the certificate. It is not recommended as an essential part of the proposed PKIX standard but may be used in local environments.
PKIX Part 1 requires that this extension be marked noncritical.

B.3.16. subjectKeyIdentifier

The Subject Key Identifier extension identifies the public key certified by this certificate. This extension provides a way of distinguishing public keys if more than one is available for a given subject name.
The value of this extension should be calculated by performing a SHA-1 hash of the certificate's DER-encoded subjectPublicKey, as recommended by PKIX. The Subject Key Identifier extension is used in conjunction with the Authority Key Identifier extension for CA certificates. If the CA certificate has a Subject Key Identifier extension, the key identifier in the Authority Key Identifier extension of the certificate being verified should match the key identifier of the CA's Subject Key Identifier extension. It is not necessary for the verifier to recompute the key identifier in this case.
PKIX Part 1 requires this extension for all CA certificates and recommends it for all other certificates.
This extension is always noncritical.