On Tue, Aug 25, 2020 at 11:41:55AM +0900, Kyotaro Horiguchi wrote:
> Thank you for the patience.
>
> At Mon, 24 Aug 2020 22:06:45 -0400, Bruce Momjian <br...@momjian.us> wrote in
> > On Tue, Aug 25, 2020 at 11:00:49AM +0900, Kyotaro Horiguchi wrote:
> > > At Mon, 24 Aug 2020 21:49:40 -0400, Bruce Momjian <br...@momjian.us>
> > > wrote in
> > > > > > Are you saying we should _require_ clientcert=verify-full when
> > > > > > 'cert'
> > > > > > authentication is used? I don't see the point of that --- I just
> > > > > > updated the docs to say doing so was duplicate behavior.
> > > > >
> > > > > I don't suggest changing the current behavior. I'm saying it is the
> > > > > way it is working and we should correctly error-out that since it
> > > > > doesn't work as specified.
> > >
> > > Sorry, I mistead you. I don't suggest verify-full is needed for cert
> > > authentication. I said we should just reject the combination
> > > cert+veriry-ca.
> >
> > OK.
> >
> > > > Uh, I don't understand what 'combination the same way with
> > > > "cert"+"no-verify"'. Right now, cert with no clientcert/verify line
> > > > works just fine. Is "no-verify" something special? Are you saying it
> > > > is any random string that would generate an error?
> > >
> > > It was delimited as "We should reject (that)" "that combination
> > > (=cert+ferify-ca)" "the same way(=error-out)" "with cert+no-verify".
> >
> > OK, and that is what your patch does, right?
>
> Yes,
>
> > And we should error out on "with cert+no-verify" just like "with
> > cert+XXXXXX", right?
>
> Currently only cert+no-verify is rejected. The patch makes "cert+verify-ca"
> be rejected.
>
> > 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 —
but it will not insist that a client certificate be presented.
Why is this useful?
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
