EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Diagnosing certificate chain validation errors when validating a certificate or signature with *AdES components.

Note: This article primarily addresses the components that perform complete chain validation out-of-the-box. In particular, these include TElX509CertificateValidator and *AdES components.

You are getting certificate chain validation errors when validating a certificate or signature with *AdES components. The certificate is apparently correct. What is going wrong?

A number of SecureBlackbox components perform deep, thorough validation of certificate chains. This process involves construction of certificate tree(s) and establishment of correctness and effectiveness of each and every certificate in this tree. In certain cases the number of certificates in the constructed tree reaches as many as 10, and the overall number of validation elements (such as CRLs and OCSP responses) up to three times more. This, together with a bunch of other factors – such as dependency on third-party offline and online services and lack of standard compliance by some CAs – can affect the flow of the validation process and pose a risk for validation failures.

So, you have come across a chain validation error (can sound like “chain validation failed” or “collected validation information is not complete” - the exact message may vary).

Good news first: in most cases when you get this error, the certificates themselves are OK, and you can tune the component to do the validation correctly with little work as described below. But before you do that work, please read the article about how TElX509CertificateValidator works. This article explains some internals of TElX509CertificateValidator class and gives you some tips for problem diagnostics.

1. The first thing to try is to make the validation procedure more tolerant to incorrectly composed certificates and validation elements. This can be done by adjusting the following properties:

	validator.MandatoryCRLCheck = false;
	validator.MandatoryOCSPCheck = false;
	validator.MandatoryRevocationCheck = true;

If the above doesn't help, let's do some further adjustments:

	validator.IgnoreCAKeyUsage = true;

2. If the validation still fails after the above adjustments, let's proceed to the second step, which includes some detective work. It is important to track down the exact element that fails; the solution will depend on the specifics of the element and a particular problem it causes. To do this, please handle the events of TElX509CertificateValidator object (note that some components, such as TElCAdESProcessor, pass the validator object they create back to the user code via the OnCertValidatorPrepared event). Inside the handlers, please log the details of the elements being checked:

Now run the code and reproduce the problem. Once done, please have a look into the log to establish the element that fails to pass the validation. The further steps to take depend on the element and the validation problem it exposes. Just a few examples of possible validation problems are:

  • the root certificate of either of the chains (e.g. “main” chain or TSA chain) is not trusted
  • some CRL or OCSP server cannot be reached due to a network-related issue
  • a firewall blocks connection to exotic (e.g. LDAP) CRL sources
  • one or more certificates are expired

Return to the list


Back to top


Got it!