VA Services

The Validation Authority (VA) module of EJBCA provides services for validating a certificate. These VA services can run on an installed EJBCA or on a standalone VA installation. The services are by default disabled and can be enabled independently at compile time.

Alias

To define aliases to certificates or CRLs, edit the configuration file conf/va.properties. This is an example on how to get your root certificate if you have defined an alias for it:

http://myhost.com:8080/certificates/search.cgi?alias=root

RFC 4387

The protocol to retrieve CRLs and certificates is described in RFC 4387.

Only CA certificates can be fetched and the attributes certHash, uri, iAndSHash and name are not implemented as they are not relevant CA certificates and CRLs.

To enable specifying that a delta CRL should be fetched, the extra parameter delta is added to the URL:

http://myhost:8080/crls/search.cgi?sKIDHash=X4NX3VF9u/tzkkGZU6M6OEffhFc&delta=

Note that the adding the delta parameter is not described in the RFC.

When searching for certificates, use iHash, sHash and sKIDHash. iHash is the ASN1 encoded DN of the issuer in a certificate and retrieves all certificates that has the same issuer, except for the root certificate. To search for root certificates, use sHash.

For information on implementing your own application accessing the VA, refer to the EJBCA junit test class org.ejbca.ui.web.protocol.CertStoreServletTest.

Database privileges

Since a pure VA only reads from the database you should consider using a read-only database user for the VA. The only write access needed to the database is the VA Publisher configured on the CA.

Monitoring and Healthcheck

When OcspKeyBindings are used to respond to OCSP requests, the regular EJBCA health-check will monitor that all marked as ACTIVE can be used to sign OCSP requests.

Step 1: On the EJBCA VA - Configure the VA

A Validation Authority installation is at first glance identical to a standard CA installation, but only a subset of services need to be activated for it to function as a VA. This means that an EJBCA installation could in practice be used as both its own CA and as a VA for another CA at the same time.

The VA is configured using the same configuration files as EJBCA. Files that are of special interest to an installation acting as a VA are va.properties, ocsp.properties, crlstore.properties and certstore.properties.

For the certificate and CRL store services, the sample file should be enough to understand how to set the VA up. For the OCSP responder, all default options for the OCSP behavior are set in the conf/ocsp.properties and conf/va.properties files and the Admin GUI (or the command line).

In the OCSP responder case, you can configure conf/cesecore.properties for Secure audit log configuration to log to database or file. The database audit log is only used for security events, that is access control and configuration change events when using the GUI or CLI.

Step 2: On the EJBCA VA - Build the VA

The VA is built in the same way as the CA. After starting JBoss, run the following command from EJBCA home directory:

If you have not disabled SSL (by setting web.nosslconfigure in web.properties file), copy tomcat.jks and truststore.jks from EJBCA_HOME/p12 directory on the CA to the EJBCA_HOME/p12 directory on the VA. You might also need to configure web.properties to use the right passwords.

Then, from EJBCA home directory, run the following commands:

Step 3: On the EJBCA CA - Data Synchronization

ENTERPRISE EDITION This is an EJBCA Enterprise Edition (EE) feature.

Data Synchronization can be performed using the EJBCA Enterprise Edition features VA Publisher or Peer System.

Step 4: On the EJBCA CA - Add a Publisher

ENTERPRISE EDITION This is an EJBCA Enterprise Edition (EE) feature.

Adding a publisher can be performed using the EJBCA Enterprise Edition using either the VA Peer Publisher (recommended) or the VA Publisher (legacy).