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 _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
