understanding x.509 certificates and certificate path validation in bw

8/3/2019 Understanding X.509 Certificates and Certificate Path Validation in BW

http://slidepdf.com/reader/full/understanding-x509-certificates-and-certificate-path-validation-in-bw 1/16

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

1

Understanding X.509 Certificates andcertificate path validation in BW

With the advent of public key cryptography (PKI), it is now possible to communicate securelywith 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:



Understanding X.509 Certificates and certificate path validation in BW


2

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.]

http://www.tibcommunity.com/plugins/SupportGuidesArticles/resources/bw/CertPathValidation/img001.JPG





3

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

name-value pairs.






5

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






6

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 twohash 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 fieldof 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 serversmay send unordered and/or incompletecertificate chains.

Certificate 0 [Server Certificate]

subject:





7

/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:



issuer:



Schematically, the hierarchy above can be expressed with the following example:





8

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






9

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 thefollowing:






10

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






12

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 certificateswhich 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.







13






14

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":





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.]

understanding x.509 certificates and certificate path validation in bw

Documents