RFE: test CRL publishing is working

[yrro]

Unless I've missed something there doesn't seem to be a health check for CRL publishing.

This would:

• Fetch https://$HOSTNAME and obtain TLS server certificate
• Obtain the CRL distribution endpoint URL (openssl x509 -in foo.crt -ext crlDistributionPoints -noout)
• Check the URL is as expected (http://ipa-ca.$suffix/ipa/crl/MasterCRL.bin)
• Fetch the CRL from $HOSTNAME
• Verify the CRL signature, obtain last & next update times(openssl crl -in MasterCRL.bin -inform der -CAfile /etc/ipa/ca.crt -noout -lastupdate -nextupdate)
• Check the system clock is >= last update time
• Check the system clock is < next update time
• Check the next update time is <= 4 hours away
• Check each certificate in the CRL:
  • check that it's revoked
  • check that it hasn't expired
• Search for certificates that have been revoked but have not expired, and verify that they are present in the CRL
• Verify that ca.certStatusUpdateInterval in /etc/pki/pki-tomcat/ca/CS.cfg is consistent with the server's status as a CRL generator (https://issues.redhat.com/browse/RHEL-30280)

I'll implement if you think that sounds useful.

[rcritten]

I guess I'd want to see what the outcome of https://pagure.io/freeipa/issue/9505 is first. If there is or can be some fundamental issue in generating the CRL then it's something we should check.

[rcritten]

The findings are that we need a check to ensure that the CRL generator server either has ca.certStatusUpdateInterval not present or greater than zero. The default is 600 seconds. If it is 0 then the cert status is not updated on this server. I imagine but didn't validate that a negative value would not be ideal.

[rcritten]

Oh and additionally require that ca.certStatusUpdateInterval=0 on non-CRL generators. The reason being avoiding replication conflicts.