On 09/15/2014 01:44 PM, Alexey Klyukin wrote:
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:
On Mon, Sep 15, 2014 at 10:23 AM, Alexey Klyukin wrote:
> On Fri, Sep 12, 2014 at 4:20 PM, Heikki Linnakangas
> 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 wort
On Fri, Sep 12, 2014 at 4:20 PM, Heikki Linnakangas
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
On 09/12/2014 01:30 PM, Heikki Linnakangas wrote:
On 09/11/2014 08:46 PM, Alexey Klyukin wrote:
On Mon, Sep 8, 2014 at 8:04 PM, Heikki Linnakangas
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
On 09/11/2014 08:46 PM, Alexey Klyukin wrote:
On Mon, Sep 8, 2014 at 8:04 PM, Heikki Linnakangas
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
On Mon, Sep 8, 2014 at 8:04 PM, Heikki Linnakangas
wrote:
> On 09/05/2014 07:30 PM, Alexey Klyukin wrote:
>> The error does not state whether the names comes from the CN or from
>> the SAN section.
>
>
> I'd reword that slightly, to:
>
> psql: server certificate for "example.com" (and 2 other nam
On 09/05/2014 07:30 PM, Alexey Klyukin wrote:
On Thu, Sep 4, 2014 at 10:23 AM, Heikki Linnakangas
wrote:
Hmm. Perhaps we should use X509_NAME_get_index_by_NID + X509_NAME_get_entry
instead of X509_NAME_get_text_by_NID. You could then pass the ASN1_STRING
object to the certificate_name_entry_va
On Thu, Sep 4, 2014 at 10:23 AM, Heikki Linnakangas
wrote:
>
> Hmm. Perhaps we should use X509_NAME_get_index_by_NID + X509_NAME_get_entry
> instead of X509_NAME_get_text_by_NID. You could then pass the ASN1_STRING
> object to the certificate_name_entry_validate_match() function, and have it
> do
On 09/04/2014 10:33 AM, Alexey Klyukin wrote:
On Wed, Sep 3, 2014 at 11:50 AM, Heikki Linnakangas
wrote:
* 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.
On Wed, Sep 3, 2014 at 11:50 AM, Heikki Linnakangas
wrote:
> * 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.
For the case of CN the caller has to do the
On 09/01/2014 09:14 PM, Alexey Klyukin wrote:
On Mon, Sep 1, 2014 at 10:39 AM, Alexey Klyukin wrote:
On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
wrote:
Yeah, I think a certificate without CN should be supported. See also RFC 6125, section
4.1. "Rules" [for issuers of certificates]:
On Mon, Sep 1, 2014 at 10:39 AM, Alexey Klyukin wrote:
> On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
> 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
On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
wrote:
>
> On 08/28/2014 07:28 PM, Alexey Klyukin wrote:
>>
>> On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>>> On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
>>>
On Wed, Aug 20, 2014 at 11:53
On 08/28/2014 07:28 PM, Alexey Klyukin wrote:
On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
The patch doesn't seem
On Mon, Aug 25, 2014 at 12:33 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 08/25/2014 01:07 PM, Andres Freund wrote:
>
>> On 2014-08-25 13:02:50 +0300, Heikki Linnakangas wrote:
>>
>>> But actually, I wonder if we should delegate the whole hostname matching
>>> to
>>> OpenSSL? The
On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
>
>> On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>>>
>>> The patch doesn't seem to support wildcards in alternati
On 08/25/2014 01:07 PM, Andres Freund wrote:
On 2014-08-25 13:02:50 +0300, Heikki Linnakangas wrote:
But actually, I wonder if we should delegate the whole hostname matching to
OpenSSL? There's a function called X509_check_host for that, although it's
new in OpenSSL 1.1.0 so we'd need to add a c
On 2014-08-25 13:02:50 +0300, Heikki Linnakangas wrote:
> But actually, I wonder if we should delegate the whole hostname matching to
> OpenSSL? There's a function called X509_check_host for that, although it's
> new in OpenSSL 1.1.0 so we'd need to add a configure test for that and keep
> the curr
On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
On 07/25/2014 07:10 PM, Alexey Klyukin wrote:
Greetings,
I'd like to propose a patch for checking subject alternative names entry
in
the SSL certificate for DN
On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 07/25/2014 07:10 PM, Alexey Klyukin wrote:
>
>> Greetings,
>>
>> I'd like to propose a patch for checking subject alternative names entry
>> in
>> the SSL certificate for DNS names during SSL authentication
On 07/25/2014 07:10 PM, Alexey Klyukin wrote:
Greetings,
I'd like to propose a patch for checking subject alternative names entry in
the SSL certificate for DNS names during SSL authentication.
Thanks! I just ran into this missing feature last week, while working on
my SSL test suite. So +1 f
Magnus Hagander writes:
> On Fri, Jul 25, 2014 at 7:15 PM, Alexey Klyukin wrote:
>> On Fri, Jul 25, 2014 at 6:34 PM, Magnus Hagander
>>> Why keep looping once you've found a match? When you set result=true
>>> you should break; from the loop I think. Not necessarily for
>>> performance, but ther
On Fri, Jul 25, 2014 at 7:15 PM, Alexey Klyukin wrote:
> On Fri, Jul 25, 2014 at 6:34 PM, Magnus Hagander
> wrote:
>>
>>
>> I just took a very quick look at the code, and just noticed one thing:
>>
>> Why keep looping once you've found a match? When you set result=true
>> you should break; from t
On Fri, Jul 25, 2014 at 6:34 PM, Magnus Hagander
wrote:
>
> I just took a very quick look at the code, and just noticed one thing:
>
> Why keep looping once you've found a match? When you set result=true
> you should break; from the loop I think. Not necessarily for
> performance, but there might
On Fri, Jul 25, 2014 at 6:10 PM, Alexey Klyukin wrote:
> Greetings,
>
> I'd like to propose a patch for checking subject alternative names entry in
> the SSL certificate for DNS names during SSL authentication.
>
> When the client PGSSLMODE is set to verify-full, the common name (CN) of the
> Post
Greetings,
I'd like to propose a patch for checking subject alternative names entry in
the SSL certificate for DNS names during SSL authentication.
When the client PGSSLMODE is set to verify-full, the common name (CN) of
the PostgreSQL server in the certificate is matched against the actual
host
26 matches
Mail list logo
