database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-16 06:01:02 +03:00
Code Activity

Add new clientcert hba option verify-full

Browse Source 
This allows a login to require both that the cn of the certificate
matches (like authentication type cert) *and* that another
authentication method (such as password or kerberos) succeeds as well.

The old value of clientcert=1 maps to the new clientcert=verify-ca,
clientcert=0 maps to the new clientcert=no-verify, and the new option
erify-full will add the validation of the CN.

Author: Julian Markwort, Marius Timmer
Reviewed by: Magnus Hagander, Thomas Munro
This commit is contained in:
Magnus Hagander
2019-03-09 12:09:10 -08:00
parent 6b9e875f72
commit 0516c61b75
7 changed files with 156 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
doc/src/sgml/client-auth.sgml
View File

@ -563,10 +563,17 @@ hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable>
<para>
In addition to the method-specific options listed below, there is one
method-independent authentication option <literal>clientcert</literal>, which
can be specified in any <literal>hostssl</literal> record. When set
to <literal>1</literal>, this option requires the client to present a valid
(trusted) SSL certificate, in addition to the other requirements of the
authentication method.
can be specified in any <literal>hostssl</literal> record.
This option can be set to <literal>verify-ca</literal> or
<literal>verify-full</literal>. Both options require the client
to present a valid (trusted) SSL certificate, while
<literal>verify-full</literal> additionally enforces that the
<literal>cn</literal> (Common Name) in the certificate matches
the username or an applicable mapping.
This behavior is similar to the cert authentication method
(see <xref linkend="auth-cert"/> ) but enables pairing
the verification of client certificates with any authentication
method that supports <literal>hostssl</literal> entries.
</para>
</listitem>
</varlistentry>
@ -1865,11 +1872,11 @@ host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapse
<para>
In a <filename>pg_hba.conf</filename> record specifying certificate
authentication, the authentication option <literal>clientcert</literal> is
assumed to be <literal>1</literal>, and it cannot be turned off since a client
certificate is necessary for this method. What the <literal>cert</literal>
method adds to the basic <literal>clientcert</literal> certificate validity test
is a check that the <literal>cn</literal> attribute matches the database
user name.
assumed to be <literal>verify-ca</literal> or <literal>verify-full</literal>,
and it cannot be turned off since a client certificate is necessary for this
method. What the <literal>cert</literal> method adds to the basic
<literal>clientcert</literal> certificate validity test is a check that the
<literal>cn</literal> attribute matches the database user name.
</para>
</sect1>

54
doc/src/sgml/runtime.sgml
View File

@ -2316,13 +2316,25 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
(<acronym>CA</acronym>s) you trust in a file in the data
directory, set the parameter <xref linkend="guc-ssl-ca-file"/> in
<filename>postgresql.conf</filename> to the new file name, and add the
authentication option <literal>clientcert=1</literal> to the appropriate
authentication option <literal>clientcert=verify-ca</literal> or
<literal>clientcert=verify-full</literal> to the appropriate
<literal>hostssl</literal> line(s) in <filename>pg_hba.conf</filename>.
A certificate will then be requested from the client during SSL
connection startup. (See <xref linkend="libpq-ssl"/> for a description
of how to set up certificates on the client.) The server will
verify that the client's certificate is signed by one of the trusted
certificate authorities.
of how to set up certificates on the client.)
</para>
<para>
For a <literal>hostssl</literal> entry with
<literal>clientcert=verify-ca</literal>, the server will verify
that the client's certificate is signed by one of the trusted
certificate authorities. If <literal>clientcert=verify-full</literal>
is specified, the server will not only verify the certificate
chain, but it will also check whether the username or its mapping
matches the <literal>cn</literal> (Common Name) of the provided certificate.
Note that certificate chain validation is always ensured when the
<literal>cert</literal> authentication method is used
(see <xref linkend="auth-cert"/>).
</para>
<para>
@ -2341,18 +2353,34 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
The <literal>clientcert</literal> authentication option is available for
all authentication methods, but only in <filename>pg_hba.conf</filename> lines
specified as <literal>hostssl</literal>. When <literal>clientcert</literal> is
not specified or is set to 0, 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.
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.
</para>
<para>
If you are setting up client certificates, you may wish to use
the <literal>cert</literal> authentication method, so that the certificates
control user authentication as well as providing connection security.
See <xref linkend="auth-cert"/> for details. (It is not necessary to
specify <literal>clientcert=1</literal> explicitly when using
the <literal>cert</literal> authentication method.)
There are two approaches to enforce that users provide a certificate during login.
</para>
<para>
The first approach makes use of the <literal>cert</literal> authentication
method for <literal>hostssl</literal> entries in <filename>pg_hba.conf</filename>,
such that the certificate itself is used for authentication while also
providing ssl connection security. See <xref linkend="auth-cert"/> for details.
(It is not necessary to specify any <literal>clientcert</literal> options
explicitly when using the <literal>cert</literal> authentication method.)
In this case, the <literal>cn</literal> (Common Name) provided in
the certificate is checked against the user name or an applicable mapping.
</para>
<para>
The second approach combines any authentication method for <literal>hostssl</literal>
entries with the verification of client certificates by setting the
<literal>clientcert</literal> authentication option to <literal>verify-ca</literal>
or <literal>verify-full</literal>. The former option only enforces that
the certificate is valid, while the latter also ensures that the
<literal>cn</literal> (Common Name) in the certificate matches
the user name or an applicable mapping.
</para>
</sect2>