Certificate -Validation in PKIX

Certificates of different types are trusted by different applications. -Therefore certificates need to be signed by certification authority (CA) and -the signature must be verified and validated. This section describes about -certificate chain and certificate validation processes.

Certificate Chain

Certificate validation is a recursive -process. It begins with the need to verify the signature on some data presented -by an End Entity (EE). This involves checking that the key pair is actually -owned by that EE. To do this the public signing key of that EE is acquired -by getting its certificate. That certificate would have been signed by the -EE's certification authority (CA), so the signature on the certificate can -be verified by getting the CA's public signing key. In turn the CA's certificate -might require verifying in which case the process is repeated until the process -bottoms out when an entity which is already trusted is reached; that entity -is usually self signed. This process is illustrated in the figure below:

- Certificate chain - -

The set of certificates from an EE up to a trusted root CA certificate -is called a certificate chain. Once a certificate chain -has been constructed ,the EE's key pair at the start can be validated.

Input to Certificate Validation

End -Entity & Intermediate Certificates

A set of certificates, -from the entity requesting authentication up to, but not including, one already -trusted by the relying party.

Where these certificates come from is -potentially a difficult problem if certificate management is expected to search -for intermediate certificates in remote repositories; however for TLS at least -servers are required to supply a complete, ordered set of certificates in -the form of DER-encoded ASN.1; so client code can just pass this into the -certificate chain object.

Trusted -Root Certificates

Authentication cannot be done entirely by software: -there must be a point at which the user confirms that they trust a particular -entity. The validation algorithm can only ascertain that if the user trusts -certificate X then they may also trust certificate Y. Certificates which the -user trusts directly are called root certificates because they are the root -of the validation chain. They are usually self-signed.

It is likely -that different applications will have different requirements about which certificates -may be considered trust roots and for the level of protection they require -for trust roots. To this end, applications will pass in a unique ID (TUid) -which Certificate and Key Management will use to identify the application, -and so work out which certificates can be considered trusted for that application.

For -additional flexibility, an overload is provided enabling clients to pass a -set of root certificates directly into the validation function.

For -more detailed discussion of the storage and management of root certificates -see Root Certificate -Management, Storage, and Client registration.

Validation -Time

The time for which validation will be performed.

Acceptable Policies

A -set of OIDs, each of which represents a certification policy acceptable to -the application. This enables client code to restrict the certificates that -may occur in a valid certificate chain. Client code does not have to specify -any preferred policies here. An empty set is interpreted as any policy.

Configuring -for Certificate Validation

The following settings can be configured -for the validation process:

- - - -

Supported critical extensions

You can list supported X.509 v3 critical extensions. Once you have -set a list, you have full control over the processing of X.509 v3 critical -extensions. If a critical extension is found whose OID matches an element -in this list, certificate validation treats this as a warning instead of an -error.

You can set, add, remove and reset the list of supported critical -extensions.

If critical extensions are not configured, the validation -process uses a default set. This includes standard X.509 critical extensions -and Symbian specific critical extensions.

- - -

Date validity checks

You can specify whether a failed check on the certificate validity -date is treated as an error or a warning. You can use this to verify the certificate -validity period post-installation. By default the certificate validity period -only needs to be checked at installation.

- - - -

Chain Validation

Chain Construction

The -chain object parses the encoded set of certificates. The first certificate -is considered to be the EE certificate, and subsequent certificates must each -certify the preceding one. The chain object then searches the set of trusted -root certificates for a certificate trusted by the client and whose subject -name matches the issuer name in the last certificate in the decoded set. If -two or more match, it will attempt to resolve this be comparing the authority -key ID in the last certificate with the subject key ID in each candidate root. -If this extension is not present, it will attempt to find a single root by -signature verification. If no root is found validation will fail immediately -with an error.

Initialisation of Chain Validation Algorithm

The -certificate chain initialises the following state variables:

Validation Time: time -for which validation is calculated. Initialised to the time supplied by client -code.
Initial Policies: set -of policy OIDs, initialised to the policies supplied by client code
Acceptable Policies: -set of X.509 policy information objects, initially any policy
Mapped Policies: set -of policy OIDs, initially empty
Excluded Subtrees: set -of X.500 General Name objects, initially empty
Permitted Subtrees: -set of X.500 General Name objects, initially any subtree
Max Path Length: integer -representing the maximum path length. Initially the actual path length
Inhibit Policy Mapping: -integer whose value is the number of certificates that may appear after the -current one before policy mapping is no longer permitted. Initially the chain -length
Require Explicit Policy: -integer whose value is the number of certificates that may appear after the -current one before an acceptable policy OID must appear in the certificate. -Initially the chain length
Current Cert: integer -whose value is the position of the current certificate in the chain. Initially -the chain length -1

Validation Algorithm

Validation of a certificate -chain starts at the root and ends at the End Entity.

Validation -warnings

Validation returns warnings. Warnings enable client code -to evaluate whether irregularities are errors.

From Version 9.3, validation -returns a warning object for every certificate in the chain. Each warning -object has the following characteristics:

It includes the object's -index. Clients use the index to get the certificate from the certificate chain -object (CX509CertChain::Cert()).
It encapsulates the -warnings and the critical extensions' OID values for that certificate.

Clients can query the object for two sets of data:

the critical extensions -for the certificate
a set of warning values, -each consisting of a reason for the warning and an integer identifying the -certificate that the warning is associated with.

After querying the warning object for the critical extension, the -client must process any custom critical extensions it supplied that are not -in the supported list. This meets the X.509 certificate specification.

Prior -to version 9.3, the set of warning values returned included any warnings about -critical extensions. Warning values no longer include this information. But -backward compatibility has been maintained for warning objects prior to version -9.3.

Certificate validation steps

Certificate -validation takes place through the following steps:

Signature Verification -& Name Chaining

Each certificate must be signed by, and its subject -name should match the issuer name in, the certificate above it in the chain. -The only exception is the root certificate, which, if it claims to be self -signed (i.e. its subject and issuer names match) must really be self signed; -otherwise its signature is not verified, but a warning is generated.
Validity Period Checking

For -each certificate, the Validation Time must lie within the validity period -in the certificate. The check is always carried out. The check treats a failure -as an error or a warning depending on how the validation process is configured -(See Date validity checks in Configuring -for Certificate Validation). By default the check treats the failure -as an error.
Extension Processing

Extensions -can be marked critical. All critical extensions must be in the supported list -to be recognized and processed. When a critical extension that is not in the -supported list is encountered, an error results and validation fails. The -client must process critical extensions that are not in the supported list.
Revocation Checking

Additionally, for each certificate:

the Max Path Length, Inhibit -Policy Mapping and Require Explicit Policy variables are decremented,
and Current Cert must -be less than or equal to Max Path Length.

When validation is complete the Acceptable Policies variable -will be copied into the set of policies in the result object.

See also

PKIXCert

+ + + + + +Certificate +Validation in PKIX +

Certificates of different types are trusted by different applications. +Therefore certificates need to be signed by certification authority (CA) and +the signature must be verified and validated. This section describes about +certificate chain and certificate validation processes.

Certificate Chain

Certificate validation is a recursive +process. It begins with the need to verify the signature on some data presented +by an End Entity (EE). This involves checking that the key pair is actually +owned by that EE. To do this the public signing key of that EE is acquired +by getting its certificate. That certificate would have been signed by the +EE's certification authority (CA), so the signature on the certificate can +be verified by getting the CA's public signing key. In turn the CA's certificate +might require verifying in which case the process is repeated until the process +bottoms out when an entity which is already trusted is reached; that entity +is usually self signed. This process is illustrated in the figure below:

+ Certificate chain + +

The set of certificates from an EE up to a trusted root CA certificate +is called a certificate chain. Once a certificate chain +has been constructed ,the EE's key pair at the start can be validated.

Input to Certificate Validation

End +Entity & Intermediate Certificates

A set of certificates, +from the entity requesting authentication up to, but not including, one already +trusted by the relying party.

Where these certificates come from is +potentially a difficult problem if certificate management is expected to search +for intermediate certificates in remote repositories; however for TLS at least +servers are required to supply a complete, ordered set of certificates in +the form of DER-encoded ASN.1; so client code can just pass this into the +certificate chain object.

Trusted +Root Certificates

Authentication cannot be done entirely by software: +there must be a point at which the user confirms that they trust a particular +entity. The validation algorithm can only ascertain that if the user trusts +certificate X then they may also trust certificate Y. Certificates which the +user trusts directly are called root certificates because they are the root +of the validation chain. They are usually self-signed.

It is likely +that different applications will have different requirements about which certificates +may be considered trust roots and for the level of protection they require +for trust roots. To this end, applications will pass in a unique ID (TUid) +which Certificate and Key Management will use to identify the application, +and so work out which certificates can be considered trusted for that application.

For +additional flexibility, an overload is provided enabling clients to pass a +set of root certificates directly into the validation function.

For +more detailed discussion of the storage and management of root certificates +see Root Certificate +Management, Storage, and Client registration.

Validation +Time

The time for which validation will be performed.

Acceptable Policies

A +set of OIDs, each of which represents a certification policy acceptable to +the application. This enables client code to restrict the certificates that +may occur in a valid certificate chain. Client code does not have to specify +any preferred policies here. An empty set is interpreted as any policy.

Configuring +for Certificate Validation

The following settings can be configured +for the validation process:

+ + + +

Supported critical extensions

You can list supported X.509 v3 critical extensions. Once you have +set a list, you have full control over the processing of X.509 v3 critical +extensions. If a critical extension is found whose OID matches an element +in this list, certificate validation treats this as a warning instead of an +error.

You can set, add, remove and reset the list of supported critical +extensions.

If critical extensions are not configured, the validation +process uses a default set. This includes standard X.509 critical extensions +and Symbian specific critical extensions.

+ + +

Date validity checks

You can specify whether a failed check on the certificate validity +date is treated as an error or a warning. You can use this to verify the certificate +validity period post-installation. By default the certificate validity period +only needs to be checked at installation.

+ + + +

Chain Validation

Chain Construction

The +chain object parses the encoded set of certificates. The first certificate +is considered to be the EE certificate, and subsequent certificates must each +certify the preceding one. The chain object then searches the set of trusted +root certificates for a certificate trusted by the client and whose subject +name matches the issuer name in the last certificate in the decoded set. If +two or more match, it will attempt to resolve this be comparing the authority +key ID in the last certificate with the subject key ID in each candidate root. +If this extension is not present, it will attempt to find a single root by +signature verification. If no root is found validation will fail immediately +with an error.

Initialisation of Chain Validation Algorithm

The +certificate chain initialises the following state variables:

Validation Time: time +for which validation is calculated. Initialised to the time supplied by client +code.
Initial Policies: set +of policy OIDs, initialised to the policies supplied by client code
Acceptable Policies: +set of X.509 policy information objects, initially any policy
Mapped Policies: set +of policy OIDs, initially empty
Excluded Subtrees: set +of X.500 General Name objects, initially empty
Permitted Subtrees: +set of X.500 General Name objects, initially any subtree
Max Path Length: integer +representing the maximum path length. Initially the actual path length
Inhibit Policy Mapping: +integer whose value is the number of certificates that may appear after the +current one before policy mapping is no longer permitted. Initially the chain +length
Require Explicit Policy: +integer whose value is the number of certificates that may appear after the +current one before an acceptable policy OID must appear in the certificate. +Initially the chain length
Current Cert: integer +whose value is the position of the current certificate in the chain. Initially +the chain length -1

Validation Algorithm

Validation of a certificate +chain starts at the root and ends at the End Entity.

Validation +warnings

Validation returns warnings. Warnings enable client code +to evaluate whether irregularities are errors.

From Version 9.3, validation +returns a warning object for every certificate in the chain. Each warning +object has the following characteristics:

It includes the object's +index. Clients use the index to get the certificate from the certificate chain +object (CX509CertChain::Cert()).
It encapsulates the +warnings and the critical extensions' OID values for that certificate.

Clients can query the object for two sets of data:

the critical extensions +for the certificate
a set of warning values, +each consisting of a reason for the warning and an integer identifying the +certificate that the warning is associated with.

After querying the warning object for the critical extension, the +client must process any custom critical extensions it supplied that are not +in the supported list. This meets the X.509 certificate specification.

Prior +to version 9.3, the set of warning values returned included any warnings about +critical extensions. Warning values no longer include this information. But +backward compatibility has been maintained for warning objects prior to version +9.3.

Certificate validation steps

Certificate +validation takes place through the following steps:

Signature Verification +& Name Chaining

Each certificate must be signed by, and its subject +name should match the issuer name in, the certificate above it in the chain. +The only exception is the root certificate, which, if it claims to be self +signed (i.e. its subject and issuer names match) must really be self signed; +otherwise its signature is not verified, but a warning is generated.
Validity Period Checking

For +each certificate, the Validation Time must lie within the validity period +in the certificate. The check is always carried out. The check treats a failure +as an error or a warning depending on how the validation process is configured +(See Date validity checks in Configuring +for Certificate Validation). By default the check treats the failure +as an error.
Extension Processing

Extensions +can be marked critical. All critical extensions must be in the supported list +to be recognized and processed. When a critical extension that is not in the +supported list is encountered, an error results and validation fails. The +client must process critical extensions that are not in the supported list.
Revocation Checking

Additionally, for each certificate:

the Max Path Length, Inhibit +Policy Mapping and Require Explicit Policy variables are decremented,
and Current Cert must +be less than or equal to Max Path Length.

When validation is complete the Acceptable Policies variable +will be copied into the set of policies in the result object.