</para>

  <note>
   <para>
    It is possible to have authentication without encryption overhead by
    using <literal>NULL-SHA</literal> or <literal>NULL-MD5</literal> ciphers.  However,
    a man-in-the-middle could read and pass communications between client
    and server.  Also, encryption overhead is minimal compared to the
    overhead of authentication.  For these reasons NULL ciphers are not
    recommended.
   </para>
  </note>
  </sect2>

  <sect2 id="ssl-client-certificates">
   <title>Using Client Certificates</title>

  <para>
   To require the client to supply a trusted certificate,
   place certificates of the root certificate authorities
   (<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=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.)
  </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>
   Intermediate certificates that chain up to existing root certificates
   can also appear in the <xref linkend="guc-ssl-ca-file"/> file if
   you wish to avoid storing them on clients (assuming the root and
   intermediate certificates were created with <literal>v3_ca</literal>
   extensions).  Certificate Revocation List (CRL) entries are also
   checked if the parameter <xref linkend="guc-ssl-crl-file"/> or
   <xref linkend="guc-ssl-crl-dir"/> is set.
  </para>

  <para>
   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, the server verifies the client certificate against its CA
   file only if a client certificate is presented and the CA is configured.
  </para>

  <para>
   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