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-12 10:30:17 |
Message-ID: | 5412CB39.7090202@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/11/2014 08:46 PM, Alexey Klyukin wrote:
> On Mon, Sep 8, 2014 at 8:04 PM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> 2. I still wonder if we should follow the RFC 6125 and not check the Common
>> Name at all, if SANs are present. I don't really understand the point of
>> that rule, and it seems unlikely to pose a security issue in practice,
>> because surely a CA won't sign a certificate with a bogus/wrong CN, because
>> an older client that doesn't look at the SANs at all would use the CN
>> anyway. But still... what does a Typical Web Browser do?
>
> At least Firefox and Safari seem to follow RFC strictly, according to
> some anecdotical evidences (I haven't got enough time to dig into the
> source code yet):
>
> http://superuser.com/questions/230136/primary-common-name-in-subjectaltname
> https://bugzilla.mozilla.org/show_bug.cgi?id=238142
>
> Chrome seem to follow them, so the major open-source browsers are
> ignoring the Common Name if the SubjectAltName is present.
> Still, I see no win in ignoring CN (except for the shorter code), it
> just annoys some users that forgot to put the CN name also in the SAN
> section, so my 5 cents is that we should check both.
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.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-09-12 11:22:46 | END_OF_RECOVERY shutdowns and ResetUnloggedRelations() |
Previous Message | Andres Freund | 2014-09-12 09:51:54 | Re: Scaling shared buffer eviction |