Re: implement subject alternative names support for SSL connections

On 09/12/2014 01:30 PM, Heikki Linnakangas wrote:
> On 09/11/2014 08:46 PM, Alexey Klyukin wrote:
>> On Mon, Sep 8, 2014 at 8:04 PM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>>> 2. I still wonder if we should follow the RFC 6125 and not check the Common
>>> Name at all, if SANs are present. I don't really understand the point of
>>> that rule, and it seems unlikely to pose a security issue in practice,
>>> because surely a CA won't sign a certificate with a bogus/wrong CN, because
>>> an older client that doesn't look at the SANs at all would use the CN
>>> anyway. But still... what does a Typical Web Browser do?
>>
>> At least Firefox and Safari seem to follow RFC strictly, according to
>> some anecdotical evidences (I haven't got enough time to dig into the
>> source code yet):
>>
>> http://superuser.com/questions/230136/primary-common-name-in-subjectaltname
>> https://bugzilla.mozilla.org/show_bug.cgi?id=238142
>>
>> Chrome seem to follow them, so the major open-source browsers are
>> ignoring the Common Name if the SubjectAltName is present.
>> Still, I see no win in ignoring CN (except for the shorter code), it
>> just annoys some users that forgot to put the CN name also in the SAN
>> section, so my 5 cents is that we should check both.
>
> Hmm. If that's what the browsers do, I think we should also err on the
> side of caution here. Ignoring the CN is highly unlikely to cause anyone
> a problem; a CA worth its salt should not issue a certificate with a CN
> that's not also listed in the SAN section. But if you have such a
> certificate anyway for some reason, it shouldn't be too difficult to get
> a new certificate. Certificates expire every 1-3 years anyway, so there
> must be a procedure to renew them anyway.

Committed, with that change, ie. the CN is not checked if SANs are present.

Thanks for bearing through all these iterations!

- Heikki