Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist - Mailing list pgsql-hackers

From Jim Jones
Subject Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
Date
Msg-id 960f89e0-bc63-8a22-5f3d-a977228c1264@uni-muenster.de
Whole thread Raw
In response to Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist  (Cary Huang <cary.huang@highgo.ca>)
Responses Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
List pgsql-hackers
On 27.01.23 21:13, Cary Huang wrote:

> I agree that it is a more elegant approach to add 
> "sslcertmode=disable" on the client side to prevent sending default 
> certificate.
>
> But, if the server does request clientcert but client uses 
> "sslcertmode=disable" to connect and not give a certificate, it would 
> also result in authentication failure. In this case, we actually would 
> want to ignore "sslcertmode=disable" and send default certificates if 
> found.

Those are all very good points.

 > But, if the server does request clientcert but client uses 
"sslcertmode=disable" to connect and not give a certificate, it would 
also result in authentication failure. In this case, we actually would 
want to ignore "sslcertmode=disable" and send default certificates if 
found.

I'm just wondering if this is really necessary. If the server asks for a 
certificate and the user explicitly says "I don't want to send it", 
shouldn't it be ok for the server return an authentication failure? I 
mean, wouldn't it defeat the purpose of "sslcertmode=disable"? Although 
it might be indeed quite handy I'm not sure how I feel about explicitly 
telling the client to not send a certificate and having it being sent 
anyway :)

Best, Jim


Attachment

pgsql-hackers by date:

Previous
From: Marcos Pegoraro
Date:
Subject: Re: pg_stat_statements and "IN" conditions
Next
From: Dmitry Dolgov
Date:
Subject: Re: pg_stat_statements and "IN" conditions