Académique Documents
Professionnel Documents
Culture Documents
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.]
The Details tab displays all of the certificate attributes, including the X.509 v3 extensions, as name-value pairs.
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.
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
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.
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:
/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:
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
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:
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
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.
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.
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
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.]