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

From: Cary Huang <cary(dot)huang(at)highgo(dot)ca>
To: Israel Barth Rubio <barthisrael(at)gmail(dot)com>, Jacob Champion <jchampion(at)timescale(dot)com>
Cc: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Jelte Fennema <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
Date: 2023-01-27 20:13:32
Message-ID: 728472f9-0366-39fe-67c0-d6ef125eae28@highgo.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2023-01-27 20:34:13 Re: GUCs to control abbreviated sort keys
Previous Message Tom Lane 2023-01-27 20:06:37 Re: Optimizing PostgreSQL with LLVM's PGO+LTO