The tool is independent of EJBCA version.

Configuration properties are validated before the testing starts.

The OCSP command works as a real OCSP client sending requests to the configured OCSP responder(s).

The OCSP client can query multiple servers by specifying multiple "url" arguments at the command line. In addition, if multiple responders are behind an load balancer or VIP the queries in the CA configuration files can be configured to look for responses from specific responders by specifying the signer certificate subject DN. Then only responses from that responder will be considered.

The maximum number of tries to perform to get a response for a query from a particular responder is configurable at the command line by specifying the maxtries argument.

Querying for multiple CAs on each server by supplying multiple CA configuration files. New files can easily be created and supplied at the command line when invoking the tool.

Querying one OK, one revoked and one unknown certificate, as configured, from each CA by specifying multiple queries in the CA configuration file with different expected status for different certificates. The check OcspCheck_ExpectedStatus verifies that the status is the expected and OcspCheck_ExpectedSigner outputs if a response was received from the expected responder.

Verifying that the returned certificate chain in the OCSP response is good by adding the check called OcspCheck_CertificateChain.A basic certificate chain check is performed with the configured issuer certificate as trust anchor. More complex chains or chains where the responder certificate is not signed by the configured issuer might fail.

Verifying that the returned OCSP response verifies by adding the check called OcspCheck_Response_verify.

Verifying that the OCSP response is returned timely (configurable max time) by adding the check called OcspCheck_Response_time.

Verifying the nonce if configured to use one by adding the check called OcspCheck_Nonce.

Verifying that the right extensions are used by adding the checks called OcspCheck_Extensions_required and OcspCheck_Extensions_allowed.

The signer certificate can be validated with the same set of checks and configuration as with the certificate checks tool by adding the check called OcspCheck_SignerCertificate and configure it with the name of a certificate checks configuration file.

The tool is configured with a configuration file pointing out a template certificate that can be used by the different checks to compare the certificates against. The configuration file also contains details about which checks to perform.

Certificates could be exported from EJBCA to the configured certificate folder for instance using a publisher.

Verifying that the sampled certificates are identical to the template certificate (except for dynamic values) by adding the check called CertCheck_Certificate_identical.

Verifying that the sampled certificates contains issuer and subject DN components that are configured to be required by adding the checks called CertCheck_SubjectDNComponents_required and CertCheck_IssuerDNComponents_required.

Verifying that the sampled certificates does not contain other DN components than required or optional by by adding the checks called CertCheck_SubjectDNComponents_allowed and CertCheck_IssuerDNComponents_allowed and configure it with the list of allowed DN components, that is both the required and optional ones.

Verifying that the certificate contains the specified values for DN components that must be the same, i.e. O=PrimeKey,C=SE, by adding the checks called CertCheck_SubjectDNComponents_specified and CertCheck_IssuerDNComponents_specified and specify the DN parts or add the checks CertCheck_SubjectDNComponents_identical and CertCheck_IssuerDNComponents_identical to require the values of the specified DN components to be identical to those in the template certificate.

Verifying that the validity end date is at least a configurable number of hours in the future by adding the check called CertCheck_ValidityNotAfter_minRemaining.

Verifying that the validity end date is not more than a configurable number of hours in the future by adding the check called CertCheck_ValidityNotAfter_maxRemaining.

Verifying that the validity start date is not more than a configurable number of minutes from now by adding the check called CertCheck_ValidityNotBefore_maxDiffFromNow.

Verifying that the public key specification (ie. key length for RSA) is the same as in the template by adding the check called CertCheck_PublicKey_sizeEquals.

Verifying that the public key algorithm is the same as in the template by adding the check called CertCheck_PublicKey_algorithmEquals.

Verifying that the signature algorithm is the same as in the template by adding the check called CertCheck_Signature_algorithmEquals.

Verifying that the same extensions are used in the certificate as in the template and that they have the same criticality but not necessarily the same value by adding the checks called CertCheck_Extensions_criticalOIDs and CertCheck_Extensions_nonCriticalOIDs

Verifying the extensions that are configured to be identical by adding the check CertCheck_Extensions_identical which compares the DER encoded values of the extensions in the certificate with those in the template.

Verifying that the subject and issuer DN are in the correct order by adding the checks called SubjectDNOrder_specified and IssuerDNOrder_specified and specify the order of the DN components.

The tool runs as long as there are certificate files in the configured directory. When a file is analyzed, then the output is written to log files and the analyzed file is deleted. When there are no more certificate files in the configured directory, the application sleeps for a while (as configured) before checking if there are some more certificates to validate.

To make it less likely a certificate file is being analyzed before it has been completely written to disk new files will not be read until their last modified time is more than configured time in the past (for instance 2 seconds).