On Fri, Mar 11, 2016 at 10:20:49AM -0800, Christina Fu wrote: > Hi Fraser, > > I think the general idea looks good. If tested to work, I actually think > you should have it replace the current caServerCert.cfg and make it the > default server cert profile for Dogtag. So I'd suggest you name things more > generically. > Thanks Christina for the feedback. W.r.t naming, can you clarify what you think should be more generic and why?
> Just for your reference, there is an implementation that injects SAN(s) into > server certs at time of Dogtag instance creation. It also allows one to put > multiple SANs in one ssl server cert: > https://fedorahosted.org/pki/ticket/1316#comment:14 > again, it's only limited to pkispawn option so it serves a different > purpose. > > Christina > > On 03/10/2016 05:06 PM, Fraser Tweedale wrote: > >On Mon, Mar 07, 2016 at 07:33:52AM +0100, Jan Cholasta wrote: > >>Hi, > >> > >>On 29.2.2016 07:59, Fraser Tweedale wrote: > >>>Hi all (especially those interested in certificates), > >>> > >>>Please provide early review of my design for RFC 2818 compliance > >>>which will address the following tickets: > >>> > >>>- #4970 Server certificate profile should always include a Subject > >>>Alternate name for the host > >>>- #5706 [RFE] Support SAN-only certificates > >>> > >>>http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > >>> > >>>The design is a WIP and there is no code for it yet. Looking for > >>>feedback and (hopefully) validation of the approach before > >>>committing cycles to implementing new profile components in Dogtag. > >>1) Do wildcard certificates need special handling? There is no mention of > >>them in the design doc. > >> > >No special handling of wildcard certs is needed but I've added some > >commentary to the design page. > > > >>2) Should we accept invalid CSR where CN length is greater than 64? I > >>wouldn't be surprised if these existed in the wild. > >> > >Good question. I agree such CSRs probably exist. There are various > >ways to handle them: > > > >a) Reject request (with useful message; instruction to issue > > SAN-only request instead) > > > >b) Issue non-compliant cert with overlong CN. It will be helpful to > > find out how important clients handle such certs. > > > >c) Accept the CSR but "promote" the overlong CN from CSR into a SAN > > dnsName, and issue a SAN-only cert. Some clients may not handle > > such certs very well. > > > >Personally I like (c), because the user intent is clear but we still > >issue a valid cert, however, I expect there are clients out there > >(particularly in "enterprise" environments?) that will not handle it > >well. > > > >I've copied pki-devel@ to solicit additional insights here :) > > > >>3) Sometimes it is not clear which parts belong to Dogtag and which to IPA > >>itself. For example the upgrade section - I assume Dogtag should update > >>registry.cfg and IPA caIPAserviceCert profile, but it is not clearly stated > >>anywhere. > >> > >Thanks, I've added clarifying remarks. In brief: yes Dogtag should > >update registry.cfg, but FreeIPA should update the profile. > > > >Thank you for your feedback, Jan. > >Fraser > > > >_______________________________________________ > >Pki-devel mailing list > >[email protected] > >https://www.redhat.com/mailman/listinfo/pki-devel > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code _______________________________________________ Pki-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/pki-devel
