At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian <br...@momjian.us> wrote in > On Tue, Aug 25, 2020 at 03:53:20PM +0900, Kyotaro Horiguchi wrote: > > At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian <br...@momjian.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 — > > > 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.
It verifies only CA. > 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? Because we think we need any named value for every alternatives including the default value? > 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". The point of no-verify is to allow the absence of client certificate. It is similar to "prefer" in a sense that it allows the absence of availability of an SSL connection. (In a similar way to "prefer", we could "fall back" to "no client cert" SSL connection after verification failure but I think it's not worth doing.) "prefer-verify" seems right in that sense. But I'm not sure we may break backward compatibility for the reason. > > === > > 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. Thanks. -- Kyotaro Horiguchi NTT Open Source Software Center
