read access (that is, <literal>0640</literal>
   permissions).  That setup is intended for installations where certificate
   and key files are managed by the operating system.  The user under which
   the <productname>PostgreSQL</productname> server runs should then be made a
   member of the group that has access to those certificate and key files.
  </para>

  <para>
    If the data directory allows group read access then certificate files may
    need to be located outside of the data directory in order to conform to the
    security requirements outlined above.  Generally, group access is enabled
    to allow an unprivileged user to backup the database, and in that case the
    backup software will not be able to read the certificate files and will
    likely error.
  </para>

  <para>
   If the private key is protected with a passphrase, the
   server will prompt for the passphrase and will not start until it has
   been entered.
   Using a passphrase by default disables the ability to change the server's
   SSL configuration without a server restart, but see <xref
   linkend="guc-ssl-passphrase-command-supports-reload"/>.
   Furthermore, passphrase-protected private keys cannot be used at all
   on Windows.
  </para>

  <para>
   The first certificate in <filename>server.crt</filename> must be the
   server's certificate because it must match the server's private key.
   The certificates of <quote>intermediate</quote> certificate authorities
   can also be appended to the file.  Doing this avoids the necessity of
   storing intermediate certificates on clients, assuming the root and
   intermediate certificates were created with <literal>v3_ca</literal>
   extensions.  (This sets the certificate's basic constraint of
   <literal>CA</literal> to <literal>true</literal>.)
   This allows easier expiration of intermediate certificates.
  </para>

  <para>
   It is not necessary to add the root certificate to
   <filename>server.crt</filename>.  Instead, clients must have the root
   certificate of the server's certificate chain.
  </para>
  </sect2>

  <sect2 id="ssl-openssl-config">
   <title>OpenSSL Configuration</title>

  <para>
   <productname>PostgreSQL</productname> reads the system-wide
   <productname>OpenSSL</productname> configuration file. By default, this
   file is named <filename>openssl.cnf</filename> and is located in the
   directory reported by <literal>openssl version -d</literal>.
   This default can be overridden by setting environment variable
   <envar>OPENSSL_CONF</envar> to the name of the desired configuration file.
  </para>

  <para>
   <productname>OpenSSL</productname> supports a wide range of ciphers
   and authentication algorithms, of varying strength.  While a list of
   ciphers can be specified in the <productname>OpenSSL</productname>
   configuration file, you can specify ciphers specifically for use by
   the database server by modifying <xref linkend="guc-ssl-ciphers"/> in
   <filename>postgresql.conf</filename>.
  </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