Discuss this help topic in SecureBlackbox Forum
Validate the certificate
This how-to describes the low-level procedure of certificate validation. It is strongly recommended that you use TElX509CertificateValidator class instead, as described in this how-to article.
This how-to requires knowledge of X.509 certificate basics ("Certificate basics")
As described in the above article, the certificate is usually issued (created and signed) by some Certificate Authority (CA). To check that the certificate is valid it is necessary to have a certificate of the Certificate Authority. CA is a well-known organization that has its own certificate and this certificate is usually known to application when the application is created. Alternatively there can be external storage of certificates where certificates of well-known CAs are stored (Windows Certificate Storage with ROOT store is an example of such storage).
There also exist so-called self-signed certificates. Self-signed certificates are not issued by Certificate Authority, but signed by the person for whom the certificate is created. To check integrity of the self-signed certificate it is not necessary to have any other certificate.
To validate the certificate one performs several operations:
Validation of certificate with SecureBlackbox is done in several ways:
The most powerful way is to use TElCustomCertStorage.Validate method. It tries to locate issuer certificate among certificates, contained in this storage. Validate method reports the state of the certificate (whether it is valid, not valid or self-signed) and if the certificate is not valid, report why it is not valid. You must note that this method assumes that Issuer certificate is valid. It is your application's duty to check validity of issuer certificate.
So the algorithm of complete validation of the certificate is
Note, that for Issuer certificates you need to check validity time by comparing it not with current date, but with the date, when the certificate was used for signing.
Example: Certificate A was signed using certificate B on 1 November 2003. Certificate A is validated on 15 November 2003. When you validate certificate A, you need to pass 0 as ValidityMoment parameter of Validate() function. When you validate certificate B, you pass 1 November 2003 as ValidityMoment parameter.
The last step of certificate validation is to check that it is used by a e-mail sender or web site that certificate has been issued to. For example, if you connect to HTTP site, you need to check Subject Name of the certificate and compare CommonName field with the address or domain name you connect to. With E-Mail the situation is similar - you need to compare the fields of Subject parameter of certificate.
Certificate Chains
Certificate chain is a list of certificates, where all but one are CA's for other certificates in the list. Each certificate except the first one has a CA in the list, and each certificate except the last has some "child" certificate. Certificate chain can be sent by SSL server, or it can appear in the signed PKCS#7 message or in some other case.
How are certificate chains validated? First you need to gather all certificates to one instance of descendant of TElCustomCertStorage class (for example, use TElMemoryCertificateStorage for this). Each storage has Chains property, which lets you access every chain (in most cases there will be just one chain in the storage). Then you start validating certificates in the chain one by one as described above.
SecureBlackbox 5 includes TElX509CertificateChain class, which lets you access certificate chain elements in more comfortable way. Also, TElX509CertificateChain includes Validate() method which performs some validation steps automatically.
Certificate Revocation Lists (CRLs)
CRLs are usually maintained by certificate authority that issues a certificate.
CRL contains date and the reason of revocation. When the certificate is issued, Certificate Authority can include the URL of CRL, to which the certificate will be placed in case of revocation,
to certificate extension. Complete validation process should include downloading and checking the CRL for certificate.
However most of applications don't check the CRL. The reason is that not all certificates contain CRL reference, and even when they do, not all certificates are put to CRL.
Only the certificate issued by CA can be present in some revocation list.
Self-signed certificate can have no associated revocation list.
To find out, where to get the CRL for the given certificate, we must check CA certificate's extensions.
The URL of Certificate Revocation List is stored in CRL Distribution Points extension of CA certificate,
used to sign the one being verified. Note, that CRL itself is also signed (with the same CA certificate)
and also requires validation. SecureBlackbox supports CRLs via TElCertificateRevocationList class.
Online certificate status checking
There exists an alternative to CRLs, which lets you check status of the certificate from the CA, who issued this certificate, in real-time. This alternative is called OCSP, Online Certificate Status Protocol. SecureBlackbox provides OCSP client and OCSP server components which let you perform checking. For more information about OCSP requests see the corresponding how-to article.
