EJBCA support, development and maintenance by

Building and configuring the EJBCA CA

The EJBCA CA should be configured the same when installing a VA as for any other installation, in addition to setting preferences for the VA database in conf/va-publisher.properties. The VA database is the master database for standalone VA installations and where the master CA will publish certificates when they are issued or revoked.

The deploy command (ant deploy, or deploy-datasource) sets up a data source, java:/OcspDS, in JBoss (on the CA). If you use another application server you must set up this data source manually. The VA data source should be not be involved in transactions (a no-tx-datasource in JBoss), and it should have autocommit (should be default in JBoss).

Once EJBCA is been started you have to add a new publisher to the main CA server (not the VA). As a super administrator you add this publisher on the "Edit Publishers" page in the Admin GUI. Use publisher type "Validation Authority Publisher" The settings for this publisher are as follows:

• 'Data Source' - is the database of the standalone VA where this publisher will publish certificates. Use java:/OcspDS if ocsp-datasource.jndi-name=OcspDS. This must be a non-tx/jta=false data source (see Installation for instruction how to create this manually if needed).
• 'Store certificate at the Validation Authority' - stores the complete certificate on the VA. If this is unchecked only the information needed to answer OCSP requests are stored, but not the certificate itself. There are good reasons not to publish the whole certificate. It is large, thus making it a bit of heavy insert and it may contain sensitive information. On the other hand some OCSP Extension plug-ins may not work without the certificate. A regular OCSP responder works fine without the certificate. A publisher for CA certificates (used on a 'Edit Certificate Authorities' page) must have this enabled.
• 'Publish only revoked certificates' - If checked only revoked certificate are stored on the VA. The OCSP responder of the VA must have the 'nonexistingisgood' (conf/ocsp.properties) enabled if only revoked certificates are published. A publisher for CA certificates (used on a 'Edit Certificate Authorities' page) must have this disabled.
• 'Store CRL at the Validation Authority' - should be set if the CRL store service of the VA should be used for a CA (only has a meaning for publishers used on a 'Edit Certificate Authorities' page). In order to use this option you must also check 'Store certificate at the Validation Authority', and you must not check 'Publish only revoked certificates'. This is because the CA certificate(s) must also be stored in the VA when CRLs are stored there.

All certificate profiles for certificates that should be available to the OCSP responder should reference this publisher. To configure this you must be a super administrator.

All CAs that publish certificates and CRLs to the VA should have a reference to this publisher. To configure this you must be a super administrator.

Once the above is complete, all issed and revoked certificates with a profile that references a ValidationAuthorityPublisher should be published to the VA database. It's important to verify that publishing succeeds and to synchronize the databases again should it fail. See Error handling below.

Building and configuring the EJBCA VA

A Validation Authority installation is at first glance identical to a standard CA installation, but only a subset of services is activated in order to function as merely 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 of special interest to a installation acting as a VA are va.properties, ocsp.properties, crlstore.properties and certstore.properties.

For the certificate and CRL store service the sample file should be enough to understand how to set it up. For the OCSP responder service there is separate setup instructions for the Standalone OCSP installation.

The validation authority is built and deployed in the way as a CA installation with (deploy-keystore and web-configure steps is not required if you have disabled SSL, with web.nosslconfigure, in web.properties):

ant deploy
ant deploy-keystore
ant web-configure

on the VA server.

Synchronise the database of the responder

At the beginning and after failure in publishing to the VA responder, the master database of the publishers must be synchronized with the CertificateData and CRLData table of the database of EJBCA. If you only use OCSP and not CRL store, only the CertificateData table needs to be synchronized.

If there is a single certificate out of sync you can re-sync it by doing a 'Republish' from the AdminGUI.

The following procedure may be used to synchronize the database of EJBCA with the database of a pure VA instance (e.g. where all certificates are issued on another instance):

The example is for MySQL and should be adapted to your environment (database, hostnames, database name and database credentials).

1. Prevent any further issuing of new certificates and revocation of old certificates until the synchronization is finished. This might be done by simply blocking the port to the AdminGUI.
2. On the host of CA the following commands can be used to make the synchronization: Run on the OCSP responder machine (as root user in mysql):

mysql -u ejbca -p ocsp_db
mysql> drop table CertificateData;
mysql> drop table CRLData;

This drops and re-creates the tables containing certificate and CRL information. Run on the CA server:

mysqldump -u ejbca -p --compress ejbca_db CertificateData > CertificateData.dat
mysqldump -u ejbca -p --compress ejbca_db CRLData > CRLData.dat
cat CertificateData.dat | mysql -h ocspresponder ocsp_db
cat CRLData.dat | mysql -h ocspresponder ocsp_db

3. Check that the publishing is working before allowing issuing and revoking.

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.