Validation Authority Publisher (Legacy)

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

    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 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



    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/ 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.

    Handling Multiple OCSP Responders

    Additional OCSP DataSources for publishers on the CA have to be added manually. The easiest way to do this on JBoss is to 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




    and configure an additional publisher to use this new DataSource 'java:/Ocsp2DS'.
    An alternative approach for MySQL users is to use the tools for database replication. Either you could replicate CertificateData from you master EJBCA database to slave-responders or you could publish to a master OCSP responders database that in turn is replicated to the other responders. How to do it is described in the MySQL documentation. Depending on which which version you are using please read one of the following:

    Adding Additional Responders in a Live Environment

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

    1. To create the tables in the target OCSP, start JBoss AS with OCSP deployed for the first time (and then stop the server before doing the next step).

    2. Add an additional DataSource for the target OCSP responder in EJBCA.

    3. Configure a new ValidationAuthorityPublisher (Enterprise feature only) in EJCBA that uses the target OCSP DataSource. Chose to only publish to queue to accumulate all changes during the cloning.

    4. Wait one hour and check that there is nothing in the publisher-queue of the source OCSP that is older than one hour.

    5. Do a MySQL dump from the source database to the target database or use the ClientToolBox DBCOPY-command.

    6. When the copy operation has finished, configure a new Republisher Service for the target's OCSP Publisher.

    7. Make sure that the queue that built up during the copy operation is now published to the target OCSP.

    8. Run the monitoring tool (ClientToolBox OCSPMon) to verify that the new OCSP is in sync.

    9. Start the new OCSP node and add it to the pool of OCSPs in your load balancer.