From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Alexey Klyukin <alexk(at)hintbits(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: implement subject alternative names support for SSL connections |
Date: | 2014-09-03 09:50:51 |
Message-ID: | 5406E47B.4080604@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2014-09-03 10:17:55 | TODO item for protocol revision: Negotiate encryption in connection handshake |
Previous Message | Shigeru Hanada | 2014-09-03 09:16:27 | Join push-down support for foreign tables |