This article explains how to validate digital certificates using TrustedX.

Description of the digital certificate validation process

The digital certificate verification procedure is outlined in the ITU-T x509v3 standard. The results of this procedure can be:

  • Certificate valid. The digital certificate has been issued by a CA, it has not expired and it has not been revoked.
  • Certificate invalid. The digital certificate has been issued by a CA that is not trusted, it has expired, or it has been revoked.
  • The validation cannot be completed.

The procedure consists in:

  • Validating all the digital certificates in the digital certificate chain.
  • Verifying the level of trust of the different CAs and VAs used, to check the digital certificate status (e.g. to determine which level of privileges will be granted to the user).
  • Analysing the data included in the digital certificates.
  • Specifying the user's data (e.g. name, surname, organization, whether natural or legal person, NIF/CIF/VAT, etc.)

Certificate chain building, digital certificate status verification, and the later digital certificate parsing and data interpretation, are common procedures to all the applications. Nonetheless, trust management (i.e. defining which CAs will be recognized in each corporate context) is a critical issue, which must be carried out in an orchestrated, easy-to-audit manner, and which, must be in accordance with the corporate security policies.

Implementation of the digital certificate validation process with TrustedX

Where the application is concerned, the implementation of the digital certificate validation process will only, and exclusively, consist in the consumption of a TrustedX service. Furthermore, it is in the TrustedX configuration that the corporate digital certificate validation policies are applied (e.g. which CAs are recognized, how the status of a digital certificate must be checked and which data must be interpreted); the level of trust of the trusted entities is also maintained here.

In this way, the validation of a digital certificate will consist in sending a document to TrustedX and in delegating the tasks of diagnosing the level of trust of the digital certificate and executing any other operation relating to the digital certificate (e.g. obtaining the digital certificate data) to TrustedX.

TrustedX recognizes different integration architectures and its services can be used as SOAP/WS or as REST/WS (see howto “TrustedX Integration Architectures”). As in the case of the electronic signature verification services, the OASIS DSS specifications are recognized .

Next, you will see an example of a validation request for an X.509 digital certificate, which uses the OASIS DSS standard, and where, the digital certificates include the element. In addition to the validation result, the response will include a diagnosis of the level of trust of the digital certificates ( and elements):

In elements   and , TrustedX includes a specific diagnosis of the level of trust determined by the system for each digital certificate (as many as digital certificates). This diagnosis is expressed in a decimal value 0 (low trust), 1 (medium trust), 2 (trustworthy) or 3 (highly trustworthy), and in a textual value called trust label (for instance DNIe, FNMT Class2, Verisign Class3, etc.). A summary diagnosis is also included (in the element) that expresses the lowest level of trust achieved (NOTE. The overall strength of a chain is equal to the strength of its weakest link). Thus, applications can ignore any indication of complexity associated with the signature's trust (digital certificates, CRLs, OCSPs, etc.) and simply and exclusively focus on a decimal value and text string.

We use cookies to improve our website and your experience when using it. Cookies used for the essential operation of this site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.I accept cookies from this site