Vericert: Certificate validation

Guarantee the validity of your digital signature certificates

Access certificate status in real time with Vericert

Nowadays, the security of digital data is a top concern for any organization. To protect your company against data theft and potential attacks, technology based on public key methodology is available in a solution known as a Public Key Infrastructure, or PKI. Its role is to deliver digital certificates to ensure the confidentiality of data contained in the system. The validity of a PKI certificate is managed by a certificate authority (CA), which ensures an individual is authorized to possess the certificate in question.

Once a certificate has been validated, the CA signs the certificate using its root certificate. Root certificates are identified on a list available in each system using the PKI. This allows you to easily check whether a certificate has been approved by a certificate authority. Nonetheless, you must be cautious when verifying the certificate. If you only check the certificate’s signature without paying attention to the revocation date, the certificate will remain valid. This could pose a problem in certain cases.

This is why certificate revocation lists (CRLs) were invented. In most situations the CRL is sufficient, but limitations exist, which led to the emergence of the Online Certificate Status Protocol (OCSP). Hence, there are two ways to determine a certificate’s status – by querying the CRL or using an OCSP responder – but what’s the difference?

CRL vs. OCSP – What’s the difference?

A Certificate Revocation List (CRL) is a blacklist containing the IDs of certificates that are no longer trustworthy because they have been revoked or are invalid. However, even well managed lists have a big flaw. CRLs are generally refreshed every 24 hours, resulting in a period of uncertainty between the certificate status query and the list’s publication date. Here’s an example:

  • CRL publication time: 01:00:00
  • Time a valid certificate’s status was queried in the previous CRL: 06:00:00
  • Period of uncertainty regarding certificate status: 5 hours

With the increasing number of high-value transactions that use certificates and a need to legally recognize electronic signatures, experts had to develop a service capable of providing real-time information about a certificate’s status. This new protocol, named OCSP for Online Certificate Status Protocol, was designed to be a more effective and precise alternative to CRLs.

The goal of OCSP is to instantaneously verify the serial number of the certificate sent by the issuer in order to determine its validity using a whitelist. This alternative solution employs a query-response mechanism that asks the CA for very specific information, minimizing the period of uncertainty between CRL publication dates and times .

In practice, an OCSP request contains:

  • The protocol version
  • The service requested
  • Information about the certificate to determine its status
  • The extension supported by OCSP server as the signer of the request

The signed response from the responder contains:

  • The version of the protocol used to build the response
  • The response about the status of the certificate requested
  • The signature block
  • The certificate of the OCSP server queried
  • The time the response was produced
  • The exact time the response was provided (this information depends on whether the information is given in real time)

If the information is not sent instantaneously, additional information about the next update will appear, indicating when the certificate status can be verified. Depending on the client’s need, the OCSP service deploys different mechanisms to ensure the freshness of the information available to the responder.

Compared to traditional CRLs, OCSP offers several advantages, like providing information on the status of outdated certificates, and simpler processing which reduces network traffic.


The Vericert solution provides a simple, consistent and powerful way of validating certificates.


One or more validation policies can be defined in order to fulfill the needs of different applications.


Atos has a unique body of expertise, combining consulting and systems integration know-how with an in-depth understanding of corporate security technologies.

The idea is clear: an OCSP service provides a certificate’s revocation status in real time, but the Atos solution includes a range of different ways to achieve this goal:

Option 1: Directly from the database.

Option 2: If the certificate is listed in the CRL, the server provides the certificate’s revocation status as indicated.

Option 3: High capacity OCSP
When several SSL certificates are requested, the application uses a cache to respond to high demand from the platform without compromising response times (e.g. for OCSP requests concerning a frequently used certificate).

Option 4: Authenticated OCSP
OCSP can be implemented via authenticated access between the client and the platform;

Option 5:
OCSP for eIDAS-referenced certificates

  • The “archive cutoff” extension is incorporated directly into the platform and can be used to meet the requirements of qualified certificates.
  • The referenced cryptographic material is eIDAS compatible.

For optimal service, Atos’s solution combines OCSP with the timestamping protocol (TSP). Used with a digital signature system and a time source, TPS delivers proof of time to the end client. This protocol can be used to prove a document’s existence at a specific moment in time. In practice, a client sends a timestamp request to the platform, records the exact date and time, then signs and transmits this information. The responses are signed using cryptographic material featuring an interface that complies with the PKCS#11 standard.

Verifying certificate statuses is critical in any signature authentication control or validation process, and Atos provides a robust platform that employs both OCSP and TSP services.

Vericert is managed through customized web interfaces that allow remote management from a PC and a standard web browser. When a certificate must be validated according to a validation policy, Vericert is accessible via a web interface (web service) using HTTP or HTTPS (SSL). Responses can be signed. When solely querying the revocation status of a certificate, Vericert is accessible via the OCSP protocol (RFC 2560).

Standard components
  • Secure storage for CA certificates
  • CRL storage to cache CRLs obtained from predefined distribution points or using CRL distribution points (CRLDP) extensions, if present in certificates
  • OCSP client to obtain the revocation status of certificates
  • Loading the TSL (“Trusted Service List “) for AC support recognized
Validation policy customization

Using a web interface, it is possible to enter:

  • Trusted self-signed certificates
  • Certification path constituents
  • OIDs (Object Identifiers) for Certification Policies (CPs)
  • Key usage values
  • Extended key usage values as defined in RFC 5280
Optional components
  • Hardware security module (HSM) to protect the private keys used to sign validation responses or OCSP responses
  • Vericert supports different kinds of HSMs, provided either by Atos or by third parties
Norms and standards
  • Certificate format compliance with ITU-T X.509v3 and RFC 5280
  • Revocation information compliance with ITU-T X.509v3 CRL and OCSP Protocol (RFC 2560)
  • SOAP 1.1 et WSDL 1.1 for the validation of certificates against a validation policy
  • RFC 2560 for the revocation status of certificates
  • Connectivity: HTTP, LDAP and HTTPS
Policy validation

A public key certificate is validated according to a set of rules known as a validation policy. Validation policies cover various cases with different levels of complexity, but the validation of a given certificate requires at least:

  • A certification path to a Certification Authority (CA)
  • A validation policy

Once the certification path is constructed, the validity of each certificate belonging to it must be checked through CRLs or OCSP responses. Additional constraints may be defined in the validation policy, such as accepted certification policies, length of the certification path or relevant key usages.

Vericert, a centralized service for validating electronic certificates

One or more validation policies can be defined in order to fulfill the needs of different applications. As a central point for the administration of accepted CAs and revocation information, Vericert provides a simpler, more consistent and more powerful way of validating certificates.

When validating a certificate in real time, Vericert collects the required certificates, CRLs and/or OCSP responses, and hands them to the requester. This information can be entirely or partially re-used for other requests, which improves response times and reduces the load on the network.

When validating a certificate at a time in the past, the elements already collected (certificates, CRLs and/or OCSP responses) must be provided by the requester, and are then checked by Vericert.

The eIDAS regulation allows the European Union to provide a legal framework for transnational digital transactions. Its goal is to enhance trust in electronic exchanges by establishing a framework for electronic identification and trust services, including electronic signatures. Thus, the eIDAS regulation enhances the transparency and reliability of transactions.

Discover how Atos solutions can help you become compliant with eIDAS.

Learn more about it

Related resources and news

Atos cybersecurite Certificate validation PKI


Vericert – Improve and centralize the validation of public key certificates

Public key certificates allow applications to integrate security services like user authentication, non-repudiation of transactions, or confidential data exchanges. In the case of non-repudiation and data confidentiality, the validity of these certificates must be verified at the time of use and afterwards,

Interested in our Vericert certificate validation solution?