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(at)hintbits(dot)com> wrote:
>> On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)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