Deploying an OCSP architecture with high availability

Environments mandated by public key infrastructure (PKI) often require an online certificate status protocol (OCSP) architecture. Government agencies rely on OCSP to validate digital certificates. The same holds for financial and healthcare organizations.

A critical aspect of an OCSP architecture is high availability.

High availability: where standard OCSP capabilities fall short

Disruptions to OCSP services could deny access to critical systems or authentication failures. To this end, certificate status checking must remain operational as server failures, network outages, and other issues arise.

The problem: standard OCSP capabilities make it difficult to enable high availability across a distributed network.

Traditional OCSP checking setups usually rely on one server or a limited number of servers to handle certificate status requests. If a server failure or network issue occurs, disruption is likely.

There’s also the latency that comes with querying a single responder for each certificate validation request. This approach can degrade performance.

Scalability also becomes a concern. Accommodating growing demand or sudden spikes in traffic can be complex to navigate. They also come with a cost.

See also: Critical sectors can find a balance between API security and opening up to their partner ecosystem

Axway Validation Authority delivers high availability

As Cisco notes, “high availability IT systems and services are designed to be available 99.999% of the time during both planned and unplanned outages.”

In a recent demo, we showed how easy it is to achieve high availability with Axway OCSP Responders and Repeaters:

A glimpse into the inner workings of Axway OCSP

In an OCSP architecture, you always need an OCSP Responder and a certificate authority (CA) certificate. Axway Validation Authority makes this setup to easily support an Enterprise OCSP while offering flexibility in how you deploy the solution based on your needs. The way it gets deployed is dependent on how many users you need to support and if you are deploying to other geographic locations.

You can submit certificates and enter them into the required database for certificate revocation list (CRL) lists. Configuring import of certificates and CRL Imports is easy, with the option to use lightweight directory access protocol (LDAP) or HTTP.

Using LDAP vs HTTP to configure certificate imports

With LDAP, you get the benefit of being able to access all relevant CRLs.

This is for DOD DISA Certificates, and CRLs are available at LDAP Locations and already configured for you, whereas there is no HTTP server providing this type of configuration. If you were using HTTP to get Certificates and CRL Imports from DISA, you would have to configure each CRL Import location for each CA. LDAP gives you all of them at once.

While CRLs typically last seven days, their timing is configurable and typically should match the Certificate Practice Statement (CPS) on how often CRLs need to be generated. Then you match your OCSP database to match that policy to stay within security policies. Although for mission-critical operations requiring more time, like disconnected networks, you can extend the OCSP database to whatever you want.

Axway Repeaters, which are cached-based memory data it retrieves from Responders and can be used to provide quicker responses than a Responder. Also Repeaters don’t store any Keys or Certificates so are not vulnerable for key compromise or attacks. Once installed, the repeaters can automatically fetch OCSP databases and CRLs and if connection is lost users would still be able to authenticate and login to local network to perform their duties.

To install Repeaters to work with Axway Resonders, you can submit the IP so Axway Responders can interact with Axway Repeaters. Automated configuration can take you straight to an Axway Responder. You then get only the necessary certificates and CRLs and can configure them to your requirements on which certificates and crls are needed for your environment.

How Axway’s OCSP architecture supports high availability

Axway Validation Authority helps balance loads. Ideally, you will have two responders that are load balanced for high availability.

In the event of a server failure or network outage, Axway Validation Authority provides failover and high availability. Allocating traffic to different responder and repeater locations helps distribute the load and reduce costly downtime.

What happens when you have 10,000 more users entering a building and need another repeater? With Axway, you can easily balance that higher load without changing configurations. Just add additional server to Load Balanced Responders ore Repeaters and everything is already configured with same URL IP address so no need to change any configurations for users or other servers like domain controllers or web servers utilizing Axway Desktop Validator Enterprise or Standard Edition. Next blog we can discuss Desktop Validator Enterprise and Standard to explain how this helps our customers deploy enterprise OCSP for PKI environments.

Axway can support as many CAs as you want, so it is fully scalable. The solution is also CA agnostic.