This section provides a VA Services introduction and a step-by-step guide for a standalone Validation Authority (VA) installation. A Validation Authority (VA) installation is similar to a standard CA installation but only requires a subset of the services to function as a VA.
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.
CA Certificate Store
The CA certificate store allows getting a certificate chain to the root CA to verify that the certificate is signed by a valid CA (it is valid if the root is trusted). RFC 4387 specifies how the certificates are retrieved and the service is configured in the conf/certstore.properties configuration file.
To list all URLs that can be used, view the page http://vahost:8080/certificates/search.cgi when the service is enabled. To change the default URL certificates path for the web module, update the end of the URL to ejbca/publicweb/certificates/search.cgi in the EJBCA CA configuration).
The CRL store allows retrieving a signed Certificate Revocation List (CRL) of revoked certificates for a CA. RFC 4387 specifies how the CRLs are retrieved and the service is configured in the conf/crlstore.properties configuration file.
To list possible URLs, view the page http://vahost:8080/crls/search.cgi. To change the default URL crls path for the web module, update the end of the URL to ejbca/publicweb/crls/search.cgi in the EJBCA CA configuration.
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:
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:
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.
Certificate revocation information for the VA services must be present in the database of the instance acting as VA/OCSP responder.
If the issuing CA and VA instances of EJBCA uses different databases, Publishers are used to push real-time information from the CA to the VA database.
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.
Standalone VA Installation
The standalone VA installation is described in the following steps:
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.
Using VA Publisher
The EJBCA CA should be configured similar for the VA as for any other installation, with the addition of setting preferences for the VA database in conf/va-publisher.properties. The VA database is the master database for the standalone VA installations and where the master CA will publish certificates when they are issued or revoked.
In the case of the VA being an OCSP responder, the data source java:/OcspDS should be set in JBoss. The VA data source should not be involved in transactions (a no-tx-datasource in JBoss), and it should have auto-commit (should be default in JBoss). See Installation Instructions for instruction on how to create this data source if needed.
Using EJBCA Peer System
Instead of configuring va-publisher.properties, it is possible to publish certificate data through a peer connector. For information on setting up an outgoing peer connector, see Peer Systems.
Note that when setting up a new Peer System, all previously issued certificates need to be pushed to the VA. To do this, perform the following steps:
In the Admin GUI, go to Peer Systems.
Click Manage for the peer connector representing the VA and select the Certificate Data Synchronization tab.
Configure the relevant subset of information to synchronize and click Start to initiate the synchronization as a background task. The progress can be followed either in this view or in the Peer Systems overview.
The connecting system needs to be authorized to the /peerincoming /peerpublish/readcert /peerpublish/writecert /ca/[CAName] access rules to be able to check synchronization data and push missing or outdated certificate entries.