[Freeipa-users] Heads up: OCSP/CRL certificate validation issue

[Martin Kosek]

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 <mkosek at redhat.com>
Senior Software Engineer - Identity Management Team
Red Hat Inc.