Re: implement subject alternative names support for SSL connections - Mailing list pgsql-hackers

From Alexey Klyukin
Subject Re: implement subject alternative names support for SSL connections
Date
Msg-id CAAS3ty+CfNAks4uHnbqaC8rF7fgU9L9xusJ8xQ6uZ+rDZ7GQ0A@mail.gmail.com
Whole thread Raw
In response to Re: implement subject alternative names support for SSL connections  (Alexey Klyukin <alexk@hintbits.com>)
Responses Re: implement subject alternative names support for SSL connections  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Mon, Sep 15, 2014 at 10:23 AM, Alexey Klyukin <alexk@hintbits.com> wrote:
> On Fri, Sep 12, 2014 at 4:20 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>
>>> Hmm. If that's what the browsers do, I think we should also err on the
>>> side of caution here. Ignoring the CN is highly unlikely to cause anyone
>>> a problem; a CA worth its salt should not issue a certificate with a CN
>>> that's not also listed in the SAN section. But if you have such a
>>> certificate anyway for some reason, it shouldn't be too difficult to get
>>> a new certificate. Certificates expire every 1-3 years anyway, so there
>>> must be a procedure to renew them anyway.
>>
>>
>> Committed, with that change, ie. the CN is not checked if SANs are present.

Actually, I disagree with the way the patch ignores the CN. Currently,
it skips the
CN unconditionally if the SubjectAltName section is present. But what
RFC 6125 says
is:

"If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity.  Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used."

This means that we have to check that at least one dNSName resource is
present before
rejecting to examine the CN. Attached is a one-liner (excluding
comments) that fixes this.

Regards,
Alexey

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: pgbench throttling latency limit
Next
From: Heikki Linnakangas
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes