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.
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
 Pki-devel(a)redhat.com
 
https://www.redhat.com/mailman/listinfo/pki-devel