Validation Authority Publisher (Legacy)

ENTERPRISE

The legacy VA Publisher publishes issued certificates and/or revocation information to a VA instance writing them directly to the VA's database. For this reason, the VA's database has to be configured as a data source (see Validation Authority Publisher (Legacy)#VA Publisher Settings) and ports for database access need to be opened from the CA to the VA. While the functionality of this publisher has been entirely supplanted by the VA Peer Publisher (recommended), the legacy VA Publisher still remains widely in use, and has somewhat better performance than its far more secure cousin.

VA Publisher Settings

The following lists VA publisher settings.

Setting	Description
Data Source	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.
Store certificate at the Validation Authority	Stores the complete certificate on the VA. If cleared, only information needed to answer OCSP requests is 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 an Edit Certificate Authorities page) must have this enabled.
Publish only revoked certificates	If selected, only revoked certificates 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 an 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 an Edit Certificate Authorities page). Note that to use this option you must enable Store certificate at the Validation Authority and clear Publish only revoked certificates since the CA certificate(s) must be stored in the VA when CRLs are stored there.
Don't store certificate meta data except for CA and OCSP signing certificates	Personally identifiable information as relevant for the General Data Protection Regulation (GDPR) will not be transmitted to the VA. The data excluded from the VA is: subject DN subject alternative name notBefore username subject key ID end entity profile ID

Handling Multiple OCSP Responders

Additional OCSP DataSources for publishers on the CA have to be added manually. To do this on JBoss, clone the initially deployed OCSP DataSource JBOSS_HOME/server/default/deploy/ocsp-ds.xml to JBOSS_HOME/server/default/deploy/ocsp2-ds.xml and change the following:

XML

      <jndi-name>OcspDS</jndi-name>
      <connection-url>jdbc:mysql://ocsp1.domain.org:3306/ejbca</connection-url>

to:

XML

     <jndi-name>Ocsp2DS</jndi-name>
     <connection-url>jdbc:mysql://ocsp2.domain.org:3306/ejbca</connection-url>

Then configure an additional publisher to use this new DataSource java:/Ocsp2DS.

Alternatively, MySQL users can use the tools for database replication and either replicate CertificateData from upstream EJBCA database to downstream-responders or publish to an upstream OCSP responders database that in turn is replicated to the other responders. For more information, refer to the following MySQL documentation (depending on version):

Adding Additional Responders in a Live Environment

There is no automated way of pushing all certificates published to existing OCSP responders. To duplicate an existing "source" OCSP database to a "target" OCSP database, do the following:

To create the tables in the target OCSP, start JBoss AS with OCSP deployed for the first time (and then stop the server before continuing).
Add an additional DataSource for the target OCSP responder in EJBCA.
Configure a new ValidationAuthorityPublisher in EJBCA (Enterprise feature only) using the target OCSP DataSource. Select to only publish to queue to accumulate all changes during the cloning.
Wait one hour and check that there is nothing in the publisher-queue of the source OCSP that is older than one hour.
Do a MySQL dump from the source database to the target database or use the ClientToolBox DBCOPY-command.
When the copy operation has finished, configure a new Republisher Service for the target's OCSP Publisher.
Make sure that the queue that built up during the copy operation is now published to the target OCSP.
Run the monitoring tool (ClientToolBox OCSPMon) to verify that the new OCSP is in sync.
Start the new OCSP node and add it to the pool of OCSPs in your load balancer.