Nexus OCSP Responder overview
With Nexus OCSP Responder a client can, via the OCSP responder protocol, receive the status of one or more certificates and get up to date information on their revocation status. For more information about the OCSP protocol, see Introduction to the OCSP protocol. The OCSP protocol is used to get more timely revocation information than is possible with CRLs/CILs and can also be used to obtain additional status information. The OCSP protocol specifies the data that needs to be exchanged between an application checking the status of a certificate and the server providing that status.
Features
Nexus OCSP Responder is Common Criteria EAL4+ certified according to the international standard Common Criteria EAL4+ for Information Technology Security Evaluation (CC).
Use different sources of revocation information
Due to modular validation design, Nexus OCSP Responder can use different sources of revocation information. Revocation information is obtained from X.509 CRLs, complete and delta.
CRLs can be:
pushed directly from Nexus Certificate Manager (CM),
or, if another Certification Authorities (CA) than CM is used, retrieved from LDAP directories or web servers.
Forward requests to remote responders
OCSP requests can optionally be forwarded to remote OCSP responders.
This allows the front-end responder (that is, the first responder that receives an OCSP request) to act as proxy server for OCSP requests (it is then called a forwarding responder), and forward the request to a remote OCSP responder. That responder (the remote responder) need not be exposed in DMZ.
The front-end responder can both answer OCSP requests regarding certificates issued by one or several CAs, and it can also act as a forwarding responder.
Use revocation data from several CAs
One single installation of Nexus OCSP Responder can use revocation data from several Certification Authorities (CAs). Multiple instances of responders can be configured to enable separation of different CAs to individual URLs. Alternatively can one responder URL represent all hosted CAs.
Use advanced caching schemes
Nexus OCSP Responder uses advanced caching schemes to reduce network traffic and cut load peaks. Access to Nexus OCSP Responder can be controlled through TLS or by enforcing signed requests.
Support for standards
Nexus OCSP Responder has support for RFC 6960 and the extended revoked definition to respond with whether a certificate was ever issued by a CA. This can also be used as a method to activate an issued certificate only when an issuer-defined criteria has been fulfilled. This prevents the use of the certificate until it is activated.
Nexus Certificate Manager informs Nexus OCSP Responder on issued or activated certificates via the Nexus proprietary Certificate Issuance List format (CIL). The CIL contains a list of issued certificate serial numbers and is signed by the CA to provide trust equivalent to a signed Certificate Revocation List (CRL).
Nexus OCSP Responder has support for signing keys and responder certificates in Hardware Security Module (HSM), as well as in PKCS#12. See also Nexus OCSP Responder requirements and interoperability.
Collect statistics for billing
Billing logs enable to collect statistics for charging customers based on a number of queried certificates over defined time-periods. See Access control and billing and OCSP responder section.
OCSP client connectivity
OCSP client connectivity over HTTP or HTTPS using signed or un-signed OCSP queries.
Use ping data
HTTP-based Ping call can be used to remotely check if the server is running. Useful for load balancers detecting which responders that are available and for routing of OCSP traffic accordingly. See OCSP responder section.