Certificate chain and its construction

A program, which needs to check the trustfulness of a client or server certificate, has to create the certificate chain ending with a root certificate and/or any certificate with explicitly expressed trustfulness for the related program or system.

If the assembling algorithm successfully reach a CA root certificate, there is also possible that the root certificate is not trusted, because it's neither one of the "well-known trusted root" certificates issued by CA as Thawte or VeriSign, nor it is explicitly trusted.

Here is the algorithm (source: Felix Dörre):

  1. If cert is "trusted" explicitly (i. e. it was marked as such by the user, or it belongs to "well-known trusted root" certificates, exit the check completely with "trusted" - the certificate chain is successfully created.
  2. For all certs "parent" that match the issuer of "cert" in their "subject":
  3. validate its signature, validity by expiration date, revocation by the CRL, chaining,
  4. recurse on (1) with parent.
  5. Return "untrusted" - the certificate chain (to one trusted) could not be created.

Thus, for CAcert certificates, the certificate chain consists usually of 3 or 2 certificates, depending whether your client/server certificate is signed/issued with an intermediate class3 root certificate, or with the root class1 certificate, respectively.


FAQ/CertChainConstruction (last edited 2016-01-01 09:17:04 by AlesKastner)