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

From Cary Huang
Subject Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
Date
Msg-id 728472f9-0366-39fe-67c0-d6ef125eae28@highgo.ca
Whole thread Raw
In response to Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist  (Israel Barth Rubio <barthisrael@gmail.com>)
Responses Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
List pgsql-hackers
 > I think the sslcertmode=disable option that I introduced in [1] solves
 > this issue too; would it work for your case? That whole patchset is
 > meant to tackle the general case of the problem you've described.
 >
 > (Eventually I'd like to teach the server not to ask for a client
 >  certificate if it's not going to use it.)

there is an option in pg_hba.conf on the server side called "clientcert" 
that can be specified besides the auth method that controls if certain 
client connections are required to send client certificate for 
additional verification. The value of "clientcert" can be "verify-ca" or 
"verify-full". For example:

hostssl    all             all             127.0.0.1/32 md5 
clientcert=verify-full

If clientcert is not requested by the server, but yet the client still 
sends the certificate, the server will still verify it. This is the case 
in this discussion.

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.

It would perhaps to better change the parameter to 
"defaultclientcert=on-demand" on the client side that will:

1. not send the existing default certificate if server does not request 
a certificate
2. send the existing default certificate if server does request a 
certificate while the client does not use "sslcert" parameter to specify 
another non-default certificate

I put "default" in the parameter name to indicate that it only applies 
to default certificate. If user specifies a non-default certificate 
using "sslcert" parameter, "defaultclientcert" should not be used and 
client should give error if both exists.


Cary Huang
--------------------------------
HighGo Software Canada
www.highgo.ca





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Optimizing PostgreSQL with LLVM's PGO+LTO
Next
From: Jeff Davis
Date:
Subject: Re: GUCs to control abbreviated sort keys