#1365 Allow efficient CRL publishing to a set of OCSP clones
Closed: migrated 3 years ago by dmoluguw. Opened 8 years ago by jmagne.

When solving ticket #1058, in order to get OCSP clones working, we discovered an anomaly in the behavior of the CRL publishing to the set of cloned OCSPs.

The current code was calling for each OCSP clone to separately register itself as a publishing target with the mater CA. Thus the OCSP mater and all of its direct clones would receive the CRL update straight from the CA. This is not optimal since the clones by definition enjoy multi master DB replication, which gives all the clones updates when the master OCSP receives the CRL publish.

As a short term solution, we have configured ONLY the master OCSP to register itself for publishing. Here we enjoy replication but also suffer from a single point of failure issue. If the OCSP master goes down and misses a scheduled update, the clones will happily serve possibly stale data. They would only be updated the next time the since restarted master OCSP is updated.

Ways to deal with this:

  1. One way to deal with this with no changes (somewhat) is to employ something of a podded arrangement. Here say 4 separate OCSP responders can be configured. Then off of each "master" a number of clones can be created off that master. Then if the high availability is used to route requests to one of the 4 masters, we still have a usable situation. If one of the master OCSP systems are down, the user would be sent to another "pod".

  2. The best way to fix this is to do the following:

  3. The installation procedure of an OCSP master or clone, should register itself to the CA, but provide some more information that tells the CA, that they are a member of some "group" of clones to be treated specially.

  4. The CA servlet that fields these registration requests will take the new information and modify the configuration with enough information for the publishing system to tell that it is dealing with a group of clones.

  5. The publishing system, at a level to be determined, should be modified to recognize the group of clones and process the publishing to them in the following fashion:

a) Publish to the first member of the group, probably the master.
b) If that publish is a success, we are done. Replication will update the clones.
c) If that publish fails, we proceed to the next OCSP system in the list.
d) Use the same logic in b and c until we have one that succeeds.
e) Once we have a good publish, the rest of the list will be ignored.

Notes: The publishing system is quite flexible and somewhat complex. We want to find the exact correct place to insert this logic.


Per CS/DS meeting of 05/04/2015: 10.3

Metadata Update from @jmagne:
- Issue set to the milestone: UNTRIAGED

7 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1927

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Metadata Update from @dmoluguw:
- Issue close_status updated to: migrated
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata