Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: "cert" + clientcert=verify-ca in pg_hba.conf?
Date: 2020-08-25 14:04:44
Message-ID: 20200825140444.GE32540@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 25, 2020 at 03:53:20PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian <bruce(at)momjian(dot)us> wrote in
> > > > I don't see "no-verify" mentioned anywhere in our docs.
> > >
> > > no-verify itself is mentioned here.
> > >
> > > https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CLIENT-CERTIFICATES
> >
> > Oh, I see it now, thanks. Do you have any idea what this part of the
> > docs means?
> >
> > When <literal>clientcert</literal> is not specified or is set to
> > <literal>no-verify</literal>, the server will still verify any presented
> > client certificates against its CA file, if one is configured &mdash;
> > but it will not insist that a client certificate be presented.
>
> Ah.. Indeed.
>
> Even if clientcert is not set or set to no-verify, it checks client
> certificate against the CA if any. If verify-ca, client certificate
> must be provided. As the result, no-verify actually fails if client
> had a certificate that is not backed by the CA.

I think there are a few problems here. In the docs, it says "will still
verify", but it doesn't say if it verifies the CA, or the CA _and_ the
CN/username.

Second, since it is optional, what value does it have?

> > Why is this useful?
>
> I agree, but there seems to be an implementation reason for the
> behavior. To identify an hba-line, some connection parameters like
> user name and others sent over a connection is required. Thus the
> clientcert option in the to-be-identified hba-line is unknown prior to
> the time SSL connection is made. So the documentation might need
> amendment. Roughly something like the following?

Well, I realize internally we need a way to indicate clientcert is not
used, but why do we bother exposing that to the user as a named option?

And you are right that the option name 'no-verify' is wrong since it
will verify the CA if it exists, so it more like 'optionally-verify',
which seems useless from a user interface perspective.

I guess the behavior of no-verify matches our client-side
sslmode=prefer, but at least that has the value of using SSL if
available, which prevents user-visible network traffic, but doesn't
force it, but I am not sure what the value of optional certificate
verification is, since verification is all it does. I guess it should
be called "prefer-verify".

> ===
> When <literal>clientcert</literal> is not specified or is set
> to<literal>no-verify</literal>, clients can connect to server without
> having a client certificate.
>
> Note: Regardless of the setting of <literal>clientcert</literal>,
> connection can end with failure if a client certificate that cannot be
> verified by the server is stored in the ~/.postgresql directory.
> ===
>
> By the way, the following table line might need to be changed?
>
> libpq-ssl.html:
>
> > <entry><filename>~/.postgresql/postgresql.crt</filename></entry>
> > <entry>client certificate</entry>
> - <entry>requested by server</entry>
>
> The file is actually not requested by server, client just pushes to
> server if any, unconditionally.
>
> + <entry>sent to server</entry>

I have just applied this change to all branches, since it is an
independent fix. Thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-08-25 14:05:03 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Peter Eisentraut 2020-08-25 14:01:49 Re: renaming configure.in to configure.ac