On 09/01/2014 09:14 PM, Alexey Klyukin wrote:
On Mon, Sep 1, 2014 at 10:39 AM, Alexey Klyukin <al...@hintbits.com> wrote:
On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
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"
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: