Understanding X.

509 Certificates and certificate path validation in BW

With the advent of public key cryptography (PKI), it is now possible to communicate securely with untrusted parties over the Internet without prior arrangement. One of the necessities arising from such communication is the ability to accurately verify someone's identity (i.e. whether the person you are communicating with is indeed the person who he/she claims to be). In order to be able to perform identity check for a given entity, there should be a fool-proof method of binding the entity's public key to its unique domain name (DN). A X.509 digital certificate issued by a well known certificate authority (CA), like Verisign, Entrust, Thawte, etc., provides a way of positively identifying the entity by placing trust on the CA to have performed the necessary verifications. A X.509 certificate is a cryptographically sealed data object that contains the entity's unique DN, public key, serial number, validity period, and possibly other extensions. [Note: Refer to RFC 3280 ( ) for a complete list of attributes and X.509 v3 extensions.] Certificates are typically stored in PEM (Privacy Enhanced Mail) format. If you open a certificate file in a text editor, it would look like the following:

Generated by Clearspace on 2011-01-26-06:00 1

Understanding X.509 Certificates and certificate path validation in BW

The Windows OS offers a Certificate Viewer utility which allows you to double-click on any certificate and review its attributes in a human-readable format. For instance, the "General" tab in the Certificate Viewer Window (see below) shows who the certificate was issued to as well as the certificate's issuer, validation period and usage functions. [Note: Certificate files typically have a .cer extension on Windows.]

Generated by Clearspace on 2011-01-26-06:00 2

Understanding X.509 Certificates and certificate path validation in BW

The Details tab displays all of the certificate attributes, including the X.509 v3 extensions, as name-value pairs.

Generated by Clearspace on 2011-01-26-06:00 3

Understanding X.509 Certificates and certificate path validation in BW

The Certification Path tab contains the hierarchy for the chain of certificates. It allows you to select the certificate issuer or a subordinate certificate and then click on View Certificate to open the certificate in the Certificate Viewer.

Generated by Clearspace on 2011-01-26-06:00 4

Understanding X.509 Certificates and certificate path validation in BW

Each end-user certificate is signed by its issuer -- a trusted CA -- by taking a hash value (MD5 or SHA-1) of ASN.1 DER (Distinguished Encoding Rule)-encoded object and then encrypting the resulting hash with the issuers private key. The encrypted data is stored in

Generated by Clearspace on 2011-01-26-06:00 5

Understanding X.509 Certificates and certificate path validation in BW

the signatureValue attribute of the entitys public certificate. Once the certificate is signed by the issuer, a party who wishes to communicate with this entity can then take the entitys public certificate and find out who the issuer of the certificate is. Once the issuers certificate is identified, it would be possible to decrypt the value of the signatureValue attribute in the entity's certificate using the issuers public key to retrieve the hash value. This hash value will be compared with the independently calculated hash on the entity's certificate. If the two hash values match, then the information contained within the certificate must not have been altered and, therefore, one must trust that the CA has done enough background check to ensure that all details in the entitys certificate are accurate. The process of cryptographically checking the signatures of all certificates in the certificate chain is called key chaining. An additional check that is essential to key chaining is verifying that the value of the subjectKeyIdentifier extension in one certificate matches the same in the subsequent certificate. Similarly, the process of comparing the subject field of the issuer certificate to the issuer field of the subordinate certificate is called name chaining. In this process, these values must match for each pair of adjacent certificates in the certification path in order to guarantee that the path represents unbroken chain of entities relating directly to one another and that it has no missing links.

BusinessWorks Certificate Path Validation Process

The underlying security library for BusinessWorks (BW) performs path validation on the sequence of certificates that is presented by the server. These can be classified into the following set of checks:
Name chaining Key chaining Duplicate certificates Syntax check Integrity check Validity period check Criticality check Key usage check

Below is a complete and ordered set of sample certificates that a SSL-enabled server would ideally present to BW. In real life, however, one must realize that some SSL-enabled servers may send unordered and/or incompletecertificate chains. Certificate 0 [Server Certificate] subject:

Generated by Clearspace on 2011-01-26-06:00 6

Understanding X.509 Certificates and certificate path validation in BW

/C=US/ST=california/L=palo alto/O=xyz/OU=xyz/OU=Terms of use at www.veri sign.com/rpa (c)00/OU=For Intranet Use Only/CN=xyz.com issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https:/ /www.verisign.com/rpa (c)03/CN=VeriSign Class 3 Secure Intranet Server CA Certificate 1 [Intermediate Signer Certificate] subject: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https:/ /www.verisign.com/rpa (c)03/CN=VeriSign Class 3 Secure Intranet Server CA issuer: /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network Certificate 2 [Root Signer/Trust Anchor] subject: /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network issuer: /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network Schematically, the hierarchy above can be expressed with the following example:

Generated by Clearspace on 2011-01-26-06:00 7

Understanding X.509 Certificates and certificate path validation in BW

Name Chaining
The process of name chaining involves comparing the value of the subject field in one certificate to the issuer field in the subsequent certificate. In this case, the SSL-enabled server would present an ordered list of certificates (i.e. leaf certificate > intermediate certificate > root certificate). In cases where the certificates received are not in order, BW would internally rearrange the order such that the 0th certificate will be the leaf certificate, the 1st certificate will be the intermediate signer, and will traverse the certificate hierarchy all the way up to a trust anchor (the self-signed, root CA certificate). The comparison between

Generated by Clearspace on 2011-01-26-06:00 8

Understanding X.509 Certificates and certificate path validation in BW

the subject and issuer fields is made between adjacent certificates in order to make sure there is no broken link until a self-signed root certificate is reached.

Key Chaining
Key chaining involves checking that the key certified in each certificate verifies the digital signature on the subsequent certificate. This check establishes a cryptographic trust from the relying partys CA certificate (i.e. the trust anchor) to the public key contained in the server certificate. In our sample certificate chain, the key chaining would resemble the following:

Generated by Clearspace on 2011-01-26-06:00 9

Understanding X.509 Certificates and certificate path validation in BW

Duplicate Certificates
A misconfigured SSL-enabled server could possibly send duplicate certificates in the certificate chain. If the path includes two certificates that have matching issuer names and identical serial numbers, then the certificates would be considered duplicates. This check ensures that a duplicate certificate does not adversely alter the outcome of proper path validation, e.g. when checking the "pathlen" (path length) constraint.

Syntax Check
The certificate syntax has been defined in the X.509 profile. It includes a set of base certificate fields and extensions that allows additional information to be transmitted. Each certificate extension has its own syntax. A standard set of extensions is specified in the X.509 and PKIX profiles. The syntax of all base certificate fields as well as all known

Generated by Clearspace on 2011-01-26-06:00 10

Understanding X.509 Certificates and certificate path validation in BW

extensions must be checked to ensure that it conforms to the standards. If unknown extensions are present, their syntax need not be checked.

Integrity Check
It is necessary to verify the integrity of each certificate, as it is possible for the certificate content to be altered and replayed back to the receiving party. This check involves verifying the digital signature on the certificate. If the signature on any certificate in the path fails to verify, then the certificate must be corrupted and therefore should not be trusted.

Validity Period Check

Each certificate has a validity period, i.e. the time period during which the certified public key contained within the certificate is considered valid for use. Generally, the certificate validity period is compared with the current system time of the host machine. The validation period is represented as a SEQUENCE of two dates: the date on which the certificate validity period begins (notBefore); and the date on which the certificate validity period expires (notAfter). For example, Validity: Not Before: May 13 00:00:00 2004 GMT Not After : May 12 23:59:59 2014 GMT The Windows OS certificate viewer does not represent time in notBefore and notAfter format. It shows as Valid from and to dates, instead.

Generated by Clearspace on 2011-01-26-06:00 11

Understanding X.509 Certificates and certificate path validation in BW

Criticality Check
All certificate extensions have an indication as to whether their processing is critical to the acceptance of a given certificate. The criticality flag provides a backward/forward compatibility mechanism which enables CAs to state what should happen when a relying party that does not yet support the new extension encounters it. If an extension is flagged critical but the path validation process of the relying party does not support the extension, then the certificate cannot be used. Unknown, non-critical extensions can safely be ignored and other processing continued. This process prevents relying parties from trusting a certificate under conditions for which its issuer did not intend. Often the policy under which a certificate was issued will free its issuer from liability, if the certificate is not used according to the issuers specific policy, including the processing of all critical extensions in the certificate. For instance, if the Basic Constraints extension is marked critical, then the relying party should be aware that this certificate can have other subordinate certificates which it has signed. Moreover, if the pathlen attribute is present, then it should indicate the number of chain levels that can be present under that particular CA certificate.

Generated by Clearspace on 2011-01-26-06:00 12

Understanding X.509 Certificates and certificate path validation in BW

Generated by Clearspace on 2011-01-26-06:00 13

Understanding X.509 Certificates and certificate path validation in BW

Key Usage Check

The keyUsage extension is a mechanism used by the issuing CA to indicate the general use for the public key. For the server certificate this extension may be set to any one of a number of values in accord with RFC 3028 including "digitalSignature", "nonRepudiation", "keyEncipherment", "dataEncipherment", "keyAgreement", "keyCertSign", "cRLSign", "encipherOnly", and "decipherOnly". For example, if the key can be used for client authentication, the keyUsage extension would have the digitalSignature indicator set. If this is the only indicator set, such a certificate would not be appropriate for encrypting data for that subscriber. All other certificates in the path must have the "keyCertSign" indicator set in their "keyUsage" extension, indicating that these certificates can be used to verify the subject CAs signature on subsequent certificates. For example, "certificate1" has the following "keyUsages":

Generated by Clearspace on 2011-01-26-06:00 14

Understanding X.509 Certificates and certificate path validation in BW

Once all checks are performed, one can assume that the certificate chain has been cryptographically verified. If the chain verification is successfully completed, then we must decide if the chain of certificates in hand should be trusted. Making such a decision requires

Generated by Clearspace on 2011-01-26-06:00 15

Understanding X.509 Certificates and certificate path validation in BW

that a complete list of the CA certificates, from the trust anchor to the signer of the end entity certificate, be uploaded into BW's trusted certificates folder. BW, then, will load the certificates as a list in its memory during runtime and determine if the certificates presented in the chain are trustworthy. If the presented chain is incomplete, BW will try to complete the chain based on the certificates that have been uploaded to its trusted certificates folder. [Note: Refer to ARC KB107454 -- Common_Errors_in_BW_related_to_SSL.pdf -- for descriptions of all SSL-related errors thrown by BW.]

Generated by Clearspace on 2011-01-26-06:00 16