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.
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.
cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca
/var/lib/ipa/pki-ca/publish
MasterCRL-20181219-130000.der
MasterCRL.bin
/etc/httpd/conf.d/ipa.conf
/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.
/ipa/crl/MasterCRL.bin
RewriteRule ^/ipa/crl/MasterCRL.bin http://replica.ipa.example/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL
SRCH base="cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL
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:
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";)
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?
CacheDefaultExpire
Metadata Update from @cheimes: - Issue tagged with: performance
Login to comment on this ticket.