Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist

Поиск
Список
Период
Сортировка
От Cary Huang
Тема Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
Дата
Msg-id 728472f9-0366-39fe-67c0-d6ef125eae28@highgo.ca
обсуждение исходный текст
Ответ на Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist  (Israel Barth Rubio <barthisrael@gmail.com>)
Ответы Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist  (Jim Jones <jim.jones@uni-muenster.de>)
Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist  (Jacob Champion <jchampion@timescale.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Optimizing PostgreSQL with LLVM's PGO+LTO
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: GUCs to control abbreviated sort keys