Re: implement subject alternative names support for SSL connections

On Mon, Sep 15, 2014 at 10:23 AM, Alexey Klyukin <alexk@hintbits.com> wrote:
> On Fri, Sep 12, 2014 at 4:20 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>
>>> 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.

Actually, I disagree with the way the patch ignores the CN. Currently,
it skips the
CN unconditionally if the SubjectAltName section is present. But what
RFC 6125 says
is:

"If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity.  Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used."

This means that we have to check that at least one dNSName resource is
present before
rejecting to examine the CN. Attached is a one-liner (excluding
comments) that fixes this.

Regards,
Alexey