Certificate extensions were introduced in version 3. They will add flexibility to the past quite a limited format of the certificate. Each extension includes a unique object identifier (OID), criticality identifier, and value, which is the structure of ASN.1. An extension, marked as critical, must be taken and successfully processed, otherwise the certificate is rejected.
Subject Alternative Name
Subject field of the certificate used to create the connection between the subject and the public key. In practice, this approach was not flexible. It only supports hostnames, but does not specify how to handle multiple objects. Subject Alternative Name Extension replaced Subject field. It supports binding of multiple sites, which is implemented using DNS-name, IP-addresses and URI.
Extension Name Constraints used to limit the objects for which the CA can issue certificates. Namespace for object may be explicitly excluded or resolved. This feature enables organizations to create a subordinate CA that can issue certificates only for the company’s domain names. Namespace restrictions avoid the risks associated with the issuance of certificates for various sites. Certification Authority cannot do that.
According to RFC 5280, this extension should always be marked as critical, but non-critical constraints names may be used in practice. Some products do not recognize the Name Constraints, and therefore reject certificates that mark this field as critical.
Basic Constraints Extension is used to refer to CA certificates. “Path length constraint” field allows you to control the depth of the way for certificates of subordinate CAs. In theory, all CA certificates must have an extension. But in practice, some root certificates are issued in the form v1 certificates without extensions.
This extension identifies the possibility of using a key contained in the certificate. There are a limited number of ways of use, which can be set for a particular certificate. For example, CA certificate can be set Certificate Signer and CRL Signer.
Extended Key Usage
To better define or limit the using of a public key, we can specify Extended Key Usage. This field allows you to set additional goals, which depend on the OID. For example, certificates for code signing are typically have OID id-kp-codeSigning.
The extension includes a list of policies. The policy contains the OID and an additional qualifier. Qualifier usually is URI, where you can obtain the full text of the policy. The final certificates should always include at least one policy to define the rules of use of the certificate. Extension can be used to demonstrate the type of certificate validation.
CRL Distribution Points
Extension is used to specify the location of the CRL (Certificate Revocation List). The certificate must provide a CRL or OCSP information.
Authority Information Access
Authority Information Access shows you how to get some additional information and services offered by the issuing CA. One of the pieces of information – the location of the OCSP responder (in the form of HTTP URI). The parties can use the responder to verify the information on the certificate revocation. Some certificates also include URI, on which the issued certificate can be found. This is useful to create a complete certificate chain.
Subject Key Identifier
The extension contains a unique value that is used to identify certificates containing a particular public key. Ideally, the ID must be recovered from the public key. All CA certificates should include this extension and use the same identifier in the Authority Key Identifier for all issued certificates.
Authority Key Identifier
The extension defines the key that signed the certificate. It can be used in the process of making certification path in order to identify the parent certificate.
Other extensions also can be used: Inhibit anyPolicy, Issuer Alternative Name, Delta CRL Distribution Point, Policy Constraints, Policy Mappings, Subject Information Access, Subject Directory Attributes.