understanding x.509 certificates and certificate path validation in bw
Post on 07-Apr-2018
228 Views
Preview:
TRANSCRIPT
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:
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 2/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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.]
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 3/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
3
The Details tab displays all of the certificate attributes, including the X.509 v3 extensions, as
name-value pairs.
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 4/16
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 5/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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
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 6/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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:
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 7/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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:
/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:
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 8/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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
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 9/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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:
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 10/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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
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 11/16
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 12/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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.
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 13/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
13
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 14/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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":
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 15/16
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 16/16
Understanding X.509 Certificates and certificate path validation in BW
Generated by Clearspace on 2011-01-26-06:00
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.]
top related