Hello FreeIPA users! We would like to give you a heads up about a OCSP/CRL certificate validation issue introduced in FreeIPA 3.1 release (ticket 3074) we have discovered.
ISSUE: Certificates issued by FreeIPA server 3.1 and later contains 2 CRL/OCSP URIs server by Dogtag CA configured by FreeIPA: Certificate: Data: Version: 3 (0x2) Serial Number: 17 (0x11) Signature Algorithm: sha256WithRSAEncryption Issuer: O=EXAMPLE.COM, CN=Certificate Authority Validity Not Before: Apr 8 10:16:15 2013 GMT Not After : Apr 9 10:16:15 2015 GMT Subject: O=EXAMPLE.COM, CN=testcert.example.com ... X509v3 extensions: X509v3 Authority Key Identifier: keyid:9F:25:93:2F:20:2A:79:9A:A8:88:CF:CC:EB:D0:F5:43:E7:3B:B1:EE Authority Information Access: OCSP - URI:https://ipa-ca.example.com/ca/ocsp OCSP - URI:https://server1.example.com/ca/ocsp X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:https://ipa-ca.example.com/ipa/crl/MasterCRL.bin CRL Issuer: DirName: O = ipaca, CN = Certificate Authority Full Name: URI:https://server1.example.com/ipa/crl/MasterCRL.bin CRL Issuer: DirName: O = ipaca, CN = Certificate Authority ... One OCSP/CRL URI points to the original CA issuing the certificate and one points to a general URL (managed by FreeIPA) pointing to any other FreeIPA CA via CNAME/A DNS record that can serve the OCSP/CRL URI in case if the original FreeIPA CA was decommissioned or unavailable at the moment. However, we have discovered that there are 2 issues related to this change: 1) Having https in the URIs requires client (e.g. a web browser) validating the request to validate the machine serving the CRL/OCSP response itself even though the CRL/OCSP response is already signed by the CA and thus verifiable. Clients will fail to retrieve the CRL/OCSP in case of the general address as it is just a CNAME for a FreeIPA server whose certificate does not allow it to serve this address. 2) Even though we have 2 OCSP URIs in the certificate, the Firefox browser will not fail over to the general URI due to limitation in NSS which only tries the last OCSP and then fail when it is not available. HOW WE WANT TO FIX THE SITUATION: Issue 1) is being fixed by converting https in OCSP/CRL URIs to plain http as the responses are already signed and verifiable. This will allow FreeIPA CAs to serve the general URI ipa-ca.example.com. Relevant upstream tickets: https://fedorahosted.org/freeipa/ticket/3547 https://fedorahosted.org/freeipa/ticket/3552 When the issue is fixed in FreeIPA server, client certificates containing a wrong OCSP/CRL URIs can be fixed by requesting new certificates from FreeIPA CA. This task can be simplified by asking certmonger to request a new certificate for given service ("ipa-getcert resubmit" command). We plan to prepare a script automating this task on clients for your convenience. Issue 2) is more difficult to fix as it requires an enhancement to Firefox and NSS to support an OCSP fail over when a certificates contains multiple OCSP URIs. There is an open Mozilla Bugzilla with a request for this feature: https://bugzilla.mozilla.org/show_bug.cgi?id=797815 You are welcome to support our case and add your comments or use cases to this Bugzilla. If you have concerns or a question about this plan, please just add a comment. We will inform you about our next steps. Thank you. -- Martin Kosek <mko...@redhat.com> Senior Software Engineer - Identity Management Team Red Hat Inc. _______________________________________________ Freeipa-users mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-users