Re: implement subject alternative names support for SSL connections

On 09/01/2014 09:14 PM, Alexey Klyukin wrote:
> On Mon, Sep 1, 2014 at 10:39 AM, Alexey Klyukin <alexk@hintbits.com> wrote:
>> On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
>> <hlinnakangas@vmware.com> wrote:
>>> Yeah, I think a certificate without CN should be supported. See also RFC 6125, section 4.1. "Rules" [for issuers of
certificates]:
>>>
>>>>     5.  Even though many deployed clients still check for the CN-ID
>>>>         within the certificate subject field, certification authorities
>>>>         are encouraged to migrate away from issuing certificates that
>>>>         represent the server's fully qualified DNS domain name in a
>>>>         CN-ID.  Therefore, the certificate SHOULD NOT include a CN-ID
>>>>         unless the certification authority issues the certificate in
>>>>         accordance with a specification that reuses this one and that
>>>>         explicitly encourages continued support for the CN-ID identifier
>>>>         type in the context of a given application technology.
>>>
>>>
>>> Certificates without a CN-ID are probably rare today, but they might start to appear in the future.
>>
>> Ok, I will change a patch to add support for this clause.
>
> Attached is a new version. I've changed the logic to check for the SAN
> names first, and only check the common name if there is no match. The
> error when the common name is missing is only shown if SAN section
> does not contain any DNS names as well.

* It's ugly that the caller does the malloc and memcpy, and the 
certificate_name_entry_validate_match function then modifies its name 
argument. Move the malloc+memcpy inside the function.

* The error message in certificate_name_entry_validate_match says "SSL 
certificate's common name contains embedded null" even though it's also 
used for SANs.

> The tricky part is the error
> message if no match was found: initially, it only listed a single
> common name, but now tracking all DNS names just for the sake of the
> error message makes the code more bloated, so I'm wondering if simply
> stating that there was no match, as implemented in the attached patch,
> would be good enough?

Hmm. It would still be nice to say something about the certificate that 
was received. How about:
  server certificate with common name "%s" does not match host name "%s"

?

- Heikki