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>

  <sect2 id="ssl-server-files">
   <title>SSL Server File Usage</title>

   <para>
    <xref linkend="ssl-file-usage"/> summarizes the files that are
    relevant to the SSL setup on the server.  (The shown file names are default
    names.  The locally configured names could be different.)
   </para>

  <table id="ssl-file-usage">
   <title>SSL Server File Usage</title>
   <tgroup cols="3">
    <thead>
     <row>
      <entry>File</entry>
      <entry>Contents</entry>
      <entry>Effect</entry>
     </row>
    </thead>

    <tbody>

     <row>
      <entry><xref linkend="guc-ssl-cert-file"/> (<filename>$PGDATA/server.crt</filename>)</entry>
      <entry>server certificate</entry>
      <entry>sent to client to indicate server's identity</entry>
     </row>

     <row>
      <entry><xref linkend="guc-ssl-key-file"/> (<filename>$PGDATA/server.key</filename>)</entry>
      <entry>server private key</entry>
      <entry>proves server certificate was sent by the owner; does not indicate
      certificate owner is trustworthy</entry>
     </row>

     <row>
      <entry><xref linkend="guc-ssl-ca-file"/></entry>
      <entry>trusted certificate authorities</entry>
      <entry>checks that client certificate is
      signed by a trusted certificate authority</entry>
     </row>

     <row>
      <entry><xref linkend="guc-ssl-crl-file"/></entry>
      <entry>certificates revoked by certificate authorities</entry>
      <entry>client certificate must not be on this list</entry>
     </row>

    </tbody>
   </tgroup>
  </table>

   <para>
    The server reads these files at server start and whenever the server
    configuration is reloaded.  On <systemitem class="osname">Windows</systemitem>
    systems, they are also re-read whenever a new backend process is spawned
    for a new client connection.
   </para>

   <para>
    If an error in these files is detected at server start, the server will
    refuse to start.  But if an error is detected during a configuration
    reload, the files are ignored and the old SSL configuration continues to
    be used.  On <systemitem class="osname">Windows</systemitem> systems, if an error in
    these files is detected at backend start, that backend will be unable to
    establish an SSL connection.  In all these cases, the error condition is
    reported in the server log.
   </para>
  </sect2>

  <sect2 id="ssl-certificate-creation">
   <title>Creating Certificates</title>

   <para>
     To create a simple self-signed certificate for the server, valid for 365
     days, use the following <productname>OpenSSL</productname> command,
     replacing <replaceable>dbhost.yourdomain.com</replaceable> with the
     server's host name:
<programlisting>
openssl req -new -x509 -days 365 -nodes -text -out server.crt \
  -keyout server.key -subj "/CN=<replaceable>dbhost.yourdomain.com</replaceable>"
</programlisting>
    Then do: