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

[Petr Spacek]

On 10/22/2012 02:40 PM, Simo Sorce wrote:
> 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.

+5 (because was admin 9 months ago :-)

-- 
Petr^2 Spacek