[Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile

Martin Kosek mkosek at redhat.com
Thu Apr 11 11:53:57 UTC 2013


On 04/11/2013 11:30 AM, Jan Cholasta wrote:
> On 10.4.2013 09:46, Martin Kosek wrote:
>> On 04/10/2013 01:52 AM, Dmitri Pal wrote:
>>> On 04/09/2013 12:11 PM, Simo Sorce wrote:
>>>> On Tue, 2013-04-09 at 11:18 -0400, Dmitri Pal wrote:
>>>>> On 04/09/2013 10:19 AM, Simo Sorce wrote:
>>>>>> On Tue, 2013-04-09 at 16:02 +0200, Martin Kosek wrote:
>>>>>>> On 04/08/2013 05:09 PM, Martin Kosek wrote:
>>>>>>>> On 04/08/2013 03:47 PM, Dmitri Pal wrote:
>>>>>>>>> On 04/08/2013 08:42 AM, Martin Kosek wrote:
>>>>>>>>>> On 04/08/2013 10:48 AM, Jan Cholasta wrote:
>>>>>>>>>>> On 8.4.2013 10:47, Jan Cholasta wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> this patch fixes <https://fedorahosted.org/freeipa/ticket/3552>.
>>>>>>>>>>>>
>>>>>>>>>>>> Honza
>>>>>>>>>>>>
>>>>>>>>>>> Re-sending with correct subject.
>>>>>>>>>>>
>>>>>>>>>> I tested the change both for upgrades and for fresh installs and it
>>>>>>>>>> worked fine
>>>>>>>>>> both cases, even when testing with Firefox enforcing mode.
>>>>>>>>>>
>>>>>>>>>> So far, as the biggest issue in current process I see NSS not being
>>>>>>>>>> able to
>>>>>>>>>> fallback to other defined OCSP responder (I tested with Firefox 20).
>>>>>>>>>> This way,
>>>>>>>>>> Firefox will fail validating the FreeIPA site when the first tested OCSP
>>>>>>>>>> responder is not available (e.g. the original IPA CA signing the http
>>>>>>>>>> cert, or
>>>>>>>>>> an `ipa-ca.$domain` host that is currently not up).
>>>>>>>>> Have we filed a ticket with FF?
>>>>>>>> AFAIU, this is rather NSS issue, that Firefox issue. There is a bug
>>>>>>>> open for NSS:
>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=797815
>>>>>>>>
>>>>>>>> Rob seems to have more context about this bug background.
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>> We may want to wait with pushing this patch until we get some response
>>>>>>> in the
>>>>>>> NSS Bugzilla above. If our request is rejected, we may be forced to use
>>>>>>> just a
>>>>>>> single CRL/OCSP (which would be probably the general one) and thus
>>>>>>> supersede
>>>>>>> patch 123.
>>>>>> Well it will have to depend on when you create certs.
>>>>>> The first IPA server own cert should probably point at the ipa server
>>>>>> name. Then we should warn in bold letters that the user should create
>>>>>> such and such a DNS name if they did not let IPA handle DNS.
>>>>>>
>>>>>> If we can handle DNS then any other use can refer to the common name
>>>>>> which can be an A name with multiple entries (each IPA CA server should
>>>>>> be listed there by default and the record should be changed at ca
>>>>>> replicas install/decommission time, however we should allow admins to
>>>>>> add/remove names as well manually in case they want to add proxies otr
>>>>>> conceal some of the CA servers.
>>>>>>
>>>>>> We may also want to change the RA client code to use that record to
>>>>>> fetch certs.
>>>>>>
>>>>>> Simo.
>>>>>>
>>>>> I see a lot of RFEs in this comment.
>>>>> Are we going to file them?
>>>> We'll see how NSS is going to respond to the ticket, and then adjust
>>>> accordingly.
>>>>
>>>> Simo.
>>>>
>>>>
>>> Well... time to adjust... accordingly ;-)
>>>
>>
>> Oh yes, see "adjusted" tickets
>> https://fedorahosted.org/freeipa/ticket/3552
>> and
>> https://fedorahosted.org/freeipa/ticket/3547
>> with a resolution how to handle the OCSP/CRL URIs.
>>
>> This supersedes the original Jan's patch 123.
>> Martin
>>
> 
> Updated patch attached.
> 
> Honza
> 

I tested both with new installs and with upgrades. With upgrade, I just had to
use certmonger to reissue httpd certificate and then I got OCSP validation
working again (tested in Firefox with strict OCSP validation).

ACK. Pushed to master, ipa-3-1.

Martin




More information about the Freeipa-devel mailing list