In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.
An X.509 certificate binds an identity to a public key using a digital signature. A certificate contains an identity (a hostname, or an organization, or an individual) and a public key (RSA, DSA, ECDSA, ed25519, etc.), and is either signed by a certificate authority (CA) or is self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can use the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.
X.509 also defines certificate revocation lists, which are a means to distribute information about certificates that have been deemed invalid by a signing authority, as well as a certification path validation algorithm, which allows for certificates to be signed by intermediate CA certificates, which are, in turn, signed by other certificates, eventually reaching a trust anchor.
X.509 is defined by the ITU's "Standardization Sector" (ITU-T's SG17), in ITU-T Study Group 17 and is based on Abstract Syntax Notation One (ASN.1), another ITU-T standard.
History and usage X.509 was initially issued on July 3, 1988, and was begun in association with the X.500 standard. The first tasks of it was providing users with secure access to information resources and avoiding a cryptographic man-in-the-middle attack. It assumes a strict hierarchical system of certificate authorities (CAs) for issuing the certificates. This contrasts with web of trust models, like PGP, where anyone (not just special CAs) may sign and thus attest to the validity of others' key certificates.
Version 3 of X.509 includes the flexibility to support other topologies like bridges and meshes. It can be used in a peer-to-peer, OpenPGP-like web of trust, but was rarely used that way . The X.500 system has only been implemented by sovereign nations for state identity information sharing treaty fulfillment purposes, and the IETF's Public-Key Infrastructure (X.509) (PKIX) working group has adapted the standard to the more flexible organization of the Internet. In fact, the term X.509 certificate usually refers to the IETF's PKIX certificate and CRL profile of the X.509 v3 certificate standard, as specified in , commonly called PKIX for Public Key Infrastructure (X.509).
An early issue with Public Key Infrastructure (PKI) and X.509 certificates was the well known "which directory" problem. The problem is the client does not know where to fetch missing intermediate certificates because the global X.500 directory never materialized. The problem was mitigated by including all intermediate certificates in a request. For example, early web servers only sent the web server's certificate to the client. Clients that lacked an intermediate CA certificate or where to find them failed to build a valid path from the CA to the server's certificate. To work around the problem, web servers now send all the intermediate certificates along with the web server's certificate.
While PKIX refers to the IETF's or Internet's PKI standard, there are many other PKIs with different policies. For example, the US Government has its own PKI with its own policies, and the CA/Browser Forum has its own PKI with its own policies. The US Government's PKI is a massive book of over 2500 pages. If an organization's PKI diverges too much from that of the IETF or CA/Browser Forum, then the organization risks losing interoperability with common tools like web browsers, cURL, and Wget. For example, if a PKI has a policy of only issuing certificates on Monday, then common tools like cURL and Wget will not enforce the policy and allow a certificate issued on a Tuesday.
Certificates
X.509 certificates bind an identity to a public key using a digital signature. In the X.509 system, there are two types of certificates. The first is a CA certificate. The second is an end-entity certificate. A CA certificate can issue other certificates. The top level, self-signed CA certificate is sometimes called the Root CA certificate. Other CA certificates are called intermediate CA or subordinate CA certificates. An end-entity certificate identifies the user, like a person, organization or business. An end-entity certificate cannot issue other certificates. An end-entity certificate is sometimes called a leaf certificate since no other certificates can be issued below it.
An organization that wants a signed certificate requests one from a CA using a protocol like Certificate Signing Request (CSR), Simple Certificate Enrollment Protocol (SCEP) or Certificate Management Protocol (CMP). The organization first generates a key pair, keeping the private key secret and using it to sign the CSR. The CSR contains information identifying the applicant and the applicant's public key that is used to verify the signature of the CSR - and the Distinguished Name (DN) that is unique for the person, organization or business. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority.
The CSR will be validated using a Registration Authority (RA), and then the certification authority will issue a certificate binding a public key to a particular distinguished name. The roles registration authority and certification authority are usually separate business units under separation of duties to reduce the risk of fraud.
An organization's trusted root certificates can be distributed to all employees so that they can use the company PKI system. Browsers such as Internet Explorer, Firefox, Opera, Safari and Chrome come with a predetermined set of root certificates pre-installed, so SSL certificates from major certificate authorities will work instantly; in effect the browsers' developers determine which CAs are trusted third parties for the browsers' users. For example, Firefox provides a CSV and/or HTML file containing a list of Included CAs.
X.509 and also include standards for certificate revocation list (CRL) implementations. Another IETF-approved way of checking a certificate's validity is the Online Certificate Status Protocol (OCSP). Firefox 3.0 enabled OCSP checking by default, as did versions of Windows from at least Vista and later.
Structure of a certificate The structure foreseen by the standards is expressed in a formal language, Abstract Syntax Notation One (ASN.1).
The structure of an X.509 v3 digital certificate is as follows: Certificate Version Number Serial Number Signature Algorithm ID Issuer Name Validity period Not Before Not After Subject name Subject Public Key Info Public Key Algorithm Subject Public Key Issuer Unique Identifier (optional) Subject Unique Identifier (optional) Extensions (optional) ... Certificate Signature Algorithm Certificate Signature
The Extensions field, if present, is a sequence of one or more certificate extensions. Each extension has its own unique ID, expressed as object identifier (OID), which is a set of values, together with either a critical or non-critical indication. A certificate-using system must reject the certificate if it encounters a critical extension that it does not recognize, or a critical extension that contains information that it cannot process. A non-critical extension may be ignored if it is not recognized, but must be processed if it is recognized.
The structure of version 1 is given in .
The inner format of issuer and subject unique identifiers specified in X.520 The Directory: Selected attribute types recommendation.
ITU-T introduced issuer and subject unique identifiers in version 2 to permit the reuse of issuer or subject name after some time. An example of reuse will be when a CA goes bankrupt and its name is deleted from the country's public list. After some time another CA with the same name may register itself, even though it is unrelated to the first one. However, IETF recommends that no issuer and subject names be reused. Therefore, version 2 is not widely deployed in the Internet.
Extensions were introduced in version 3. A CA can use extensions to issue a certificate only for a specific purpose (e.g. only for signing digital objects).
In all versions, the serial number must be unique for each certificate issued by a specific CA (as mentioned in ).
Extensions informing a specific usage of a certificate (and its predecessors) defines a number of certificate extensions which indicate how the certificate should be used. Most of them are arcs from the joint-iso-ccitt(2) ds(5) id-ce(29) OID. Some of the most common, defined in section 4.2.1, are:
Basic Constraints, { id-ce 19 }, are used to indicate whether the certificate is a CA certificate and can certify or issue other certificates. A constraint can be marked as critical. If a constraint is marked critical, then an agent must fail to process the certificate if the agent does not understand the constraint. An agent can continue to process a non-critical constraint it does not understand. Key Usage, { id-ce 15 }, provides a bitmap specifying the cryptographic operations which may be performed using the public key contained in the certificate; for example, it could indicate that the key should be used for signatures but not for encipherment. Extended Key Usage, { id-ce 37 }, is used, typically on a leaf certificate, to indicate the purpose of the public key contained in the certificate. It contains a list of OIDs, each of which indicates an allowed use. For example, { id-pkix 3 1 } indicates that the key may be used on the server end of a TLS or SSL connection; { id-pkix 3 4 } indicates that the key may be used to secure email.
In general when using , if a certificate has several extensions restricting its use, all restrictions must be satisfied for a given use to be appropriate. The RFC gives the specific example of a certificate containing both keyUsage and extendedKeyUsage: in this case, both must be processed and the certificate can only be used if both extensions are coherent in specifying the usage of a certificate. For example, NSS uses both extensions to specify certificate usage.
Extended Validation certificates Certification authorities operating under the CA/Browser Forum's PKI issue certificates with varying levels of validation. The different validations provide different levels of assurances that a certificate represents what it is supposed to. For example, a web server can be validated at the lowest level of assurances using an email called Domain Validation (DV). Or a web server can be validated at a higher level of assurances using more detailed methods called Extended Validation (EV).
In practice, a DV certificate means a certificate was issued for a domain like example.com after control over that domain was asserted, e.g. by responding to an email sent to [email protected]. An EV certificate means a certificate was issued for a domain like example.com, and a company like Example, LLC is the owner of the domain, and the owner was verified by Articles of Incorporation.
Extended validation does not add any additional security controls, so the secure channel setup using an EV certificate is not "stronger" than a channel setup using a different level of validation like DV.
Extended validation is signaled in a certificate using X.509 v3 extension. Each CA uses a different Object Identifier (OID) to assert extended validation. There is no single OID to indicate extended validation, which complicates user agent programming. Each user agent must have a list of OIDs that indicate extended validation.