Access certificate’s status in real time with Vericert
Nowadays, the security of computerized data is a foremost 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. The PKI’s role is to deliver digital certificates in order to ensure the confidentiality of the data contained in the system. The validity of a PKI certificate is managed by a certificate authority (CA), which checks to make sure an individual is authorized to possess the certificate (link to the PKI page) in question.
Once a certificate has been validated, the CA signs that certificate using its root certificate. Root certificates are identified on a list that is available in each system that uses the PKI. This allows you to easily check whether a certificate has been approved by a certificate authority. You must nevertheless 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, and this could pose a problem in certain cases.
That’s why certificate revocation lists (CRLs) were invented! In most situations the CRL is sufficient, but limitations do exist in some cases, which led to the emergence of the Online Certificate Status Protocol (OCSP). So, there are two ways to find out a certificate’s status – by querying the CRL or using an OCSP responder – but what’s the difference?
To follow or contact us:
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 if these lists are correctly managed by the relevant tools, the server’s response after processing the certificate contains a flaw: CRLs are generally refreshed approximately every 24 hours, resulting in a period of “uncertainty” between the certificate status query and the list’s publication date.
Here is an example:
- CRL publication time: 01:00:00
- Time a valid certificate’s status was queried in the previous CRL: 06:00:00
- Uncertainty regarding certificate status: 5 hours.
With today’s increasingly large number of high-value transactions that use certificates, coupled with the need to legally recognize electronic signatures, experts had to develop a service that would provide 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.
OCSP’s goal 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. OCSP reduces the period of uncertainty between CRL publication dates and times to a minimum.
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 being used.
Compared to traditional CRLs, OCSP offers several advantages, like providing information on the status of a certificate that is no longer up to date, and simpler processing which lightens network traffic.
This 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 built up a unique body of expertise in information systems security, bringing together know-how in consulting and systems integration and an in-depth understanding of corporate security technologies.
The idea is clear: an OCSP service gives a certificate’s revocation status in real time. But this can be done in different ways, and Atos solution implements a range of options:
Option 1: Directly from the database.
Option 2: The server gives the certificate’s revocation status as indicated in the CRL, if the certificate number is included in the CRL.
Option 3: High capacity OCSP in the case of a request for several SSL certificates. It is possible to put a cache on the application in order 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 an authenticated access between the client and the platform;
Option 5: OCSP for eIDAS-referenced certificates:
– The “archive cutoff” extension is directly incorporated into the platform and can be used to meet the requirements of qualified certificates.
– Referenced cryptographic material that is eIDAS-compatible.
For optimal service, Atos solution combines OCSP with the Time Stamping 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, for example, to attest to a document’s existence at a specific moment in time. In practice, a client sends a time stamp request to the platform – records the exact date and time – signs and transmits this information. The responses are signed using cryptographic material featuring an interface that complies with the PKCS#11 standard.
The verification of certificate statuses is a crucial phase in any process employed for signature authentication control or validation. We offer to our customers a platform featuring both OCSP and TSP services: “Time Stamping Protocol!”
Vericert is managed through the use of customized web interfaces, allowing remote management from personal computers using standard web browsers. When a certificate validation with regards to a validation policy is required, 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).
Vericert supports the following functional components
► A certificate storage used to securely store CA certificates
► A CRL storage used to cache CRLs obtained from predefined CRL distribution points or using CRL distribution points (CRLDP) extensions, if present in certificates
► An OCSP client to get the revocation status of certificates
► The loading of 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
Vericert supports the following functional optional component
► A Hardware Security Module (HSM) for the protection of the private keys used to sign validation responses or OCSP responses
► Vericert supports different kinds of HSMs, either provided by Atos or by third parties
Norms and standards for interfaces and protocols
► 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
A public key certificate is validated according to a validation policy, which is a set of rules. Validation policies cover various cases with different levels of complexity. The validation of a given certificate demands at least:
► a certification path to a Certification Authority (CA)
► a validation policy.
Once the certification path constructed, the validity of each certificate belonging to it must be checked through CRLs (Certificate Revocation Lists) or OCSP responses (On-line Certificate Status Protocol).
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, consistent and powerful way of validating certificates.
When validating a certificate at the current time, vericert collects the required certificates, CRLs and/or OCSP responses, and hands them to the requester. Information collected in order to reply to a request can be re-used, partially or not, for another request. This improves the time of response and reduces the load on the network.
When validating a certificate at a time in the past, elements already collected (certificates, CRLs and/or OCSP responses) must be provided by the requester, and then, they are checked by vericert.
The eIDAS regulation allows the European Union to provide a legal framework for transnational digital transactions. It is aiming for the enhancement of electronic exchanges’ trust. It establishes a framework for electronic identification and trust services, including the topic of the electronic signature. Thus, the eIDAS regulation enhances the transparency and reliability of transactions.
Discover how we can help you being compliant with our solutions.Learn more about it
Related resources and news
Public key certificates allow applications to integrate security services such as user authentication, non-repudiation of transactions, or confidentiality of data exchanges. The validity of these certificates needs to be verified at the time of their use and after their use, in the case of non-repudiation and data confidentiality…