Re: implement subject alternative names support for SSL connections

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.

- Heikki