The problem is there is a small but real chance that two CA's could issue CRLs at the same time with the same CRL number with different contents.

This is particularly true in this case. It makes sense to do say per-region generation but all certificates point to ipa-ca.DOMAIN so it would rely heavily on DNS to return the right location so users at least get a consistent view of things. It could easily lead to hard-to-debug "why does my browser only work sometimes" questions.

A nightmare scenario in your case would be that the isolated CRL generated right before the link came back up. If there were any revocations at all during that time on the other servers your isolated clients wouldn't know about them at all until the next generation, and assuming replication caught up, unless you also require OCSP.

That said, we can pretty easily document how to enable CRL generation manually. It's like two configuration options IIRC. We just don't recommend it for the reasons outlined. I doubt the tool would let you switch it on/off easily though unless we add some sort of switch but those tend to get abused by impatient admins who then forever-more always add --force to the command. That gets passed to junior admins and the myth is born.

And I think it might make ipa-healthcheck get upset.

Thanks for the comments.

I'm not sure we are super concerned with slightly inconsistent views. We almost never revoke certificates except when de-commissioning systems and I'm not sure how this would affect browsing.

Other thoughts on how to deal with this might be to massively increase the ca.crl.MasterCRL.nextUpdateGracePeriod to something like 3-4 days. Microsoft seems to recommend a CRL generation cycle of 1-2 weeks which also seems more reasonable in this situation than IPA's default of 4 hours.

That is a more appealing idea and I think would be trivial to implement.

As with most things in security one needs to find a balance. Since this is the dogtag default and PKI is their focus we decided not to second guess them.

I'm trying to get a sense if there are other possible issues with having multiple CRL generators (which ipa-crlgen-manage does appear to allow you to do, it just warns against having that). In particular - where does the CRL get stored? I presume in LDAP which then gets replicated to the other IPA servers. Is there any chance of the CRL getting corrupted in this process, or would simply the last CRL generated (even within a few milliseconds) win out?

It seems like the CRL number may be stored locally? I enabled another crlgen server briefly, it generated CRL number 14981. The original crlgen server reports with ipa-crlget-manage status:

CRL generation: enabled
Last CRL update: 2024-08-28 20:00:00
Last CRL Number: 14980

though when I disabled and re-enabled on the current master it did generate #14982 - so maybe the status command just gets a stale #.

IPA has PKI publish CRLs in /var/lib/ipa/pki-ca/publish/

It is possible to publish in LDAP, https://github.com/dogtagpki/pki/wiki/Publishing-CRL-to-LDAP-Server

The CRL would be stored as data so 389 would have no idea what it was handling and it would be treated like any other update. So conflict entries would be possible.

Just off the top of my head the main problem with CRL in LDAP is that it can become big, like really big. And always growing. You'd be replicating this potential gigantic thing between servers. Replication should prevent corruption otherwise we'd have bigger problems.

If in LDAP then you'd need some way to pull the data out to make it available via a URL to users. So you'd need something that ran a persistent search against it and when updated, write it out somewhere.

As for the other solution - a long grace period may make clients not check for updates to the CRL very often. I don't think this would affect ocsp users and not my freeradius config - but what about sssd?

So when you grab the CRL from ipa-ca.DOMAIN - which in our current DNS configuration could be any of the IPA servers, how do you end up with the CRL from the generator? Does the IPA server you contacted contact the CRL generator?

On servers that are not generating a CRL, there is a rewrite rule defined in /etc/httpd/conf.d/ipa-pki-proxy.conf:

RewriteRule ^/ipa/crl/MasterCRL.bin https://<hostname>/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]

So instead of reading the file from the filesystem in /var/lib/ipa/pki-ca/publish/MasterCRL.bin, the CRL is retrieved through a call to the PKI server. The call internally reads the content from LDAP below cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca (as this is replicated, it should be exactly identical between all CA masters).