EJBCA has a modular support for Publishers. A publisher can be any external source where you want to send issued certificates and CRLs to be stored.
The Publisher architecture is modular, and it is possible to implement custom publishers that can be integrated and set up in the CA UI.
Note that once created, Publishers need to be selected in a CA (publish CA certificate and CRL) or Certificate Profile (publish issued certificates) to be active, see Publishers Management.
Publisher Access Rules
The presumed administrator of publishers is the built in CA Administrator role, or more specifically a role with access to /ca_functionality/edit_publishers. Besides that, only the following publishers will be available for a given role:
- Publishers assigned to a CA that the role has access to.
- Publishers not assigned to any CA.
- ENTERPRISE EDITION Validation Authority Peer Publishers, given that the role has access to
The following covers the built-in publishers.
Publisher Queue and Failures
To achieve robust publishing there is a publisher queue. When a publisher fails the published data is stored in a separate table in the database, the PublisherQueueData. This queue can then be processed by a service, see Publisher Queue Process Service.
Publishers can also be configured not to publish directly at all, but to store everything in the queue, which is later processed. The benefit of this approach is that publishing is instant. When issuing certificates the CA does not have to wait for all publishers to finish. If there are many publishers, this might delay the issuing process slightly.
With the setting Safe direct publishing enabled, the behavior is similar to direct publishing. However, the entry will be stored to the queue before publishing, until the enrollment transaction has been verified as successful. This ensures data integrity between local and target machines in the event of a transaction rollback or other unexpected interruptions. Compared to plain direct publishing, this comes with a slight cost in enrollment performance. Safe direct publishing works only with one or more of the selected queues Use queue for CRLs, Use queue for certificates, and Use queue for OCSP responses.
The following lists available Publisher settings:
Displays the number of new entries in the queue in the intervals <1 min, 1-10 min, 10-60 min, and >60 min.
No direct publishing, only use queue
When enabled, the publisher does not try to publish directly but instead pushes the update to the queue for later processing by a Publish Queue Process Service. Since the Publish Queue Process Service does not need to run on the same node(s) that are taking external traffic, this enables you to offload the publishing work to other nodes (at the cost of delayed publishing).
|Use safe direct publishing||When enabled, the publisher temporarily stores the entry to the publisher queue until the transaction has been verified as successful, before publishing. This enables near real-time publishing, but only of events that have been properly recorded on the CA. It's recommended to start with this option first.|
Keep successfully published items in database
When enabled, items stored in the publisher queue will not be removed when real publishing has been done, status will merely be changed from PENDING to SUCCESS.
Not recommended to leave this enabled when there is a large amount of publishing. It's helpful to enable for troubleshooting publishing problems or if you require auditing of what is published for smaller PKIs.
Use queue for CRLs
Determines if the publisher queue should handle CRLs or not for this publisher. If the direct publishing fails the issued CRL is stored in the queue. If this option is not enabled the issued CRL is not published when direct publishing fails.
Use queue for certificates
Determines if the publisher queue should handle certificates or not for this publisher. If direct publishing fails the issued certificate is stored in the queue. If this option is not enabled the issued certificate is not published when direct publishing fails.
|Use queue for OCSP responses||Determines if the publisher queue should handle OCSP responses or not for this publisher. If direct publishing fails the OCSP response is stored in the queue. If this option is not enabled the OCSP response is not published when direct publishing fails.|
Failed publishing attempts are not removed from the queue, but will remain there, and up to 20,000 attempts will be made per call to the Publisher Queue Process service, in batches of 100 queue entries at the time.