#7817 Improve CRL distribution
Opened 5 months ago by cheimes. Modified 5 months ago

Request for enhancement

As admin , I want to have improved CRL distribution so that behavior and performance of CRL downloads are consistently fast. Promotion of a new CRL renewal master and demotion of an existing CRL renewal master should not require me to edit Apache config file and restart HTTPd.

Current situation

In all current releases of IPA, CRL distribution and downloads behave differently on the CRL renewal master than on all the other servers in an IPA installation.

On the CRL renewal master, Dogtag creates a new CRL every four hours. The new CRL is published to cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca in LDAP (see #7815) and the local directory /var/lib/ipa/pki-ca/publish. The LDAP entry only contains the latest CRL. The directory contains all previously created CRLs (e.g. MasterCRL-20181219-130000.der) and a symlink from MasterCRL.bin to the latest CRL. The Apache config file /etc/httpd/conf.d/ipa.conf contains a stanza to serves the directory as /ipa/crl.

On all other servers, the directory /var/lib/ipa/pki-ca/publish is empty. Only /ipa/crl/MasterCRL.bin is made available by the rewrite rule RewriteRule ^/ipa/crl/MasterCRL.bin http://replica.ipa.example/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL. A GET request to /ca/ee/ca/getCRL serves the CRL from LDAP. I performed some experiements. There seems to be no caching. Every request hits the local LDAP server with query SRCH base="cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL.

Issues

Proposal

  1. Use the same CRL serving mechanism on all servers
  2. Disable file publisher on CRL renewal master
  3. Cleanup / remove /var/lib/ipa/pki-ca/publish
  4. Cache the CRL

Change (1) would get rid of HTTP reconfiguration and restart when CRL renewal master is moved to another server. The changes (2) and (3) resolve issue #5447 (option to prune old CRLs).

Change (4) is not strictly necessary but is probably beneficial for users that use CRLs heavily. I see three ways to cache the CRLs:

  • Change the rewrite rule from redirect to proxy, then use Apache's mod_cache to cache the result temporarily.
  • Create a service that fetches the CRL from Dogtag and stores it on disk regularly.
  • Create a service that listens for LDAP changes, pulls the CRL directly from LDAP and stores it on disk.

Bonus: The service could be deployed on IPA clients and solve the issue of CRL distribution for OpenSSL clients. The service would need additional ACIs in order to access the ipaca LDAP tree:

(target="ldap:///ou=ca,o=ipaca")(targetattr="ou || objectclass")(targetfilter = "(|(ou=ca)(ou=crlIssuingPoints))")(version 3.0; acl "Authenticated users can traverse to CRL"; allow(read, search, compare) userdn="ldap:///all";)
(targetattr = "cn || objectClass || certificateRevocationList || crlNumber || nextUpdate || thisUpdate")(targetfilter = "(objectclass=crlIssuingPointRecord)")(target="ldap:///ou=crlIssuingPoints,ou=ca,o=ipaca")(version 3.0; acl "Authenticated users can read CRL"; allow(read, search, compare) userdn="ldap:///all";)

Version/Release/Distribution

freeipa-server-4.7.2-1.fc29.x86_64
freeipa-client-4.7.2-1.fc29.x86_64
package ipa-server is not installed
package ipa-client is not installed
389-ds-base-1.4.0.18-1.fc29.x86_64
pki-ca-10.6.8-3.fc29.noarch
krb5-server-1.16.1-21.fc29.x86_64


All makes sense. I'm in favour of using Apache to cache the CRL. Given the duration of the interval between CRL updates, it should be a fine approach.

Only question is: do we need to update Dogtag to return reasonable caching-related headers from the CRL servlet? Or will it suffice to just use Apache's CacheDefaultExpire directive?

Login to comment on this ticket.

Metadata