[Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name

[Simo Sorce]

On Mon, 2012-10-22 at 13:01 +0200, Martin Kosek wrote:
> On 10/22/2012 12:40 PM, Petr Spacek wrote:
> > On 10/19/2012 03:46 PM, Rob Crittenden wrote:
> >> Petr Spacek wrote:
> >>> On 10/19/2012 03:10 PM, Rob Crittenden wrote:
> >>>> Petr Spacek wrote:
> >>>>> On 10/19/2012 10:10 AM, Martin Kosek wrote:
> >>>>>> On 10/18/2012 09:42 PM, Rob Crittenden wrote:
> >>>>>>> We were seeing a unicode failure when trying to request a certificate
> >>>>>>> with
> >>>>>>> subject alt names. This one-liner should fix it.
> >>>>>>>
> >>>>>>> rob
> >>>>>>>
> >>>>>>
> >>>>>> Yup, this fixes it, works fine on --selfsign IPA CA too.
> >>>>>>
> >>>>>> Just when testing your patch, I found out we don't treat some non-DNS
> >>>>>> subject
> >>>>>> alternative name well, e.g. email extension, an we try to match it
> >>>>>> with our hosts:
> >>>>>>
> >>>>>> Certificate Request:
> >>>>>> ...
> >>>>>>          Attributes:
> >>>>>>          Requested Extensions:
> >>>>>>              X509v3 Subject Alternative Name:
> >>>>>>                  email:foo at testcert.example.com, DNS:web.example.com
> >>>>>> ...
> >>>>>>
> >>>>>> cert-request result:
> >>>>>>
> >>>>>> ipa: ERROR: no host record for subject alt name
> >>>>>> foo at testcert.example.com in
> >>>>>> certificate request
> >>>>>
> >>>>> IMHO there should be a --force option. SAN can contain a lot of
> >>>>> different things. Also, we can't assume that we manage the whole world
> >>>>> ... (now :-))
> >>>>>
> >>>>
> >>>> The intention was just to provide support for DNS alt names. I don't
> >>>> think
> >>>> requiring a host entry exist for any alt hosts is asking too much.
> >>>>
> >>>> I think a new ticket should be opened to support non-DNS alt names.
> >>>
> >>> IMHO SAN names usually contain a lot of "virtual" names like
> >>> www.shop1.com, ftp.shop1.com, etc.
> >>>
> >>> These names are usually CNAMEs to "real" name like srv1.shop1.com. In
> >>> that case host object doesn't make sense. (But SAN is required for
> >>> proper certificate validation.)
> >>
> >> The purpose is so we more tightly control was certificates are issued by our
> >> CA because we automatically issue them.
> >>
> >> rob
> > 
> > We discussed this check in Brno a bit and we found a problem:
> > 
> > 1) Each SAN has to have corresponding host object (in current implementation)
> > 2) Subject Alternative Name = other name for existing object
> >    E.g. Name www.shop1.com is CNAME for srv1.shop1.com
> > 3) Host object makes sense for "real host", not for alias like "www"
> > 4) Implication from points 1-3 => Current check can't pass in reasonable case,
> > because aliases do not have own host objects.
> > 
> > Reasonable check can be: "There have to be host object for at least one name
> > stated in certificate CN or SAN." (IMHO equivalence between CN and host object
> > name would be probably better...)
> > 
> > Does it make sense?
> > 
> 
> I am also not a big fan of current SAN check. Making sure that a host record
> for the service host exists (it does, by design) is enough IMO. As Petr said,
> SANs are often just aliases for the host, so no need for a host record.
> 
> But I think if we insist on these checks, we may add --force option to
> workaround the check or display the validation errors only as warnings (when
> the planned warning framework is ready - ticket #2732).

+1,
but I'd go further, I have found places where getting a DNS name
registered could take a couple of days (due to bad bureaucracy), in
those case you may not want to wait for that to happen, and keep going
(you can test with an entry in /etc/hosts in the meanwhile). So a
--force flag is something I think we really need.

I am all for checking and warning but outright preventing is wrong, the
admin is ultimately responsible and we shouldn't prevent admins from
doing operations unless they are fatally irreversible and would brick
the whole solution.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York