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. 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?
--
Regards,
Alexey Klyukin
