Editing X.509 (section)

==Certificate chains and cross-certification==
A '''certificate chain''' (see the equivalent concept of "certification path" defined by {{IETF RFC|5280}} section 3.2) is a list of certificates (usually starting with an end-entity certificate) followed by one or more [[Certificate authority|CA]] certificates (usually the last one being a self-signed certificate), with the following properties:
# The Issuer of each certificate (except the last one) matches the Subject of the next certificate in the list
# Each certificate (except the last one) is signed by the secret key corresponding to the next certificate in the chain (i.e. the signature of one certificate can be verified using the public key contained in the following certificate)
# The last certificate in the list is a [[trust anchor]]: a certificate that you trust because it was delivered to you by some trustworthy procedure

Certificate chains are used in order to check that the public key (PK) contained in a target certificate (the first certificate in the chain) and other data contained in it effectively belongs to its subject. In order to ascertain this, the signature on the target certificate is verified by using the PK contained in the following certificate, whose signature is verified using the next certificate, and so on until the last certificate in the chain is reached. As the last certificate is a trust anchor, successfully reaching it will prove that the target certificate can be trusted.

The description in the preceding paragraph is a simplified view on the [[certification path validation algorithm|certification path validation process]] as defined by {{IETF RFC|5280}} section 6, which involves additional checks, such as verifying validity dates on certificates, looking up [[revocation list|CRLs]], etc.

[[File:Cross-certification diagram.svg|thumb|350px|right|Example 1: Cross-certification between two PKIs]]
[[File:CA certificate renewal.png|frame|right|Example 2: CA certificate renewal]]

Examining how certificate chains are built and validated, it is important to note that a concrete certificate can be part of very different certificate chains (all of them valid). This is because several CA certificates can be generated for the same subject and public key, but be signed with different private keys (from different CAs or different private keys from the same CA). So, although a single X.509 certificate can have only one issuer and one CA signature, it can be validly linked to more than one certificate, building completely different certificate chains. This is crucial for cross-certification between PKIs and other applications.<ref>
{{cite book
  |title=Understanding Certification Path Construction
  |date=September 2002
  |publisher=PKI Forum
  |last=Lloyd
  |first=Steve
  |url=http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf
}}
</ref>
See the following examples:

===Examples===
In these diagrams:
* Each box represents a certificate, with its Subject in bold
* A → B means "A is signed by B" (or, more precisely, "A is signed by the secret key corresponding to the public key contained in B"). 
* Certificates with the same color (that are not white/transparent) contain the same public key

====Example 1: Cross-certification at root Certification Authority (CA) level between two PKIs====
In order to manage that user certificates existing in PKI 2 (like "User 2") are trusted by PKI 1, CA1 generates a certificate (cert2.1) containing the public key of CA2.<ref>
{{cite book
  |title=Qualified Subordination Deployment Scenarios
  |date=August 2009
  |publisher=Microsoft
  |section=Cross-Certification Between Root CAs
  |url=https://technet.microsoft.com/en-us/library/cc785267(v=ws.10).aspx
}}
</ref>
Now both "cert2 and cert2.1 (in green) have the same subject and public key, so there are two valid chains for cert2.2 (User 2): "cert2.2 → cert2" and "cert2.2 → cert2.1 → cert1".

Similarly, CA2 can generate a certificate (cert1.1) containing the public key of CA1 so that user certificates existing in PKI 1 (like "User 1") are trusted by PKI 2.

====Example 2: CA certificate renewal====
{{cite book
  |title=Understanding Certification Path Construction
  |date=September 2002
  |publisher=PKI Forum
  |url=http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf 
  |quote=To allow for graceful transition from the old signing key pair to the new signing key pair, the CA should issue a certificate that contains the old public key signed by the new private signing key and a certificate that contains the new public key signed by the old private signing key. Both of these certificates are self-issued, but neither is [[Self-signed certificate|self-signed]]. Note that these are in addition to the two self-signed certificates (one old, one new).
}}

Since both cert1 and cert3 contain the same public key (the old one), there are two valid certificate chains for cert5: "cert5 → cert1" and "cert5 → cert3 → cert2", and analogously for cert6. This allows that old user certificates (such as cert5) and new certificates (such as cert6) can be trusted indifferently by a party having either the new root CA certificate or the old one as trust anchor during the transition to the new CA keys.<ref>
{{cite book
  |title=PKI: Implementing and Managing E-Security
  |year=2001
  |publisher=RSA Press - Osborne/McGraw-Hill
  |last1=Nash
  |last2=Duane
  |last3=Joseph
  |last4=Brink
  |isbn=0-07-213123-3
  |section=Key and Certificate Life Cycles. CA Certificate Renewal
}}
</ref>