be stored offline for use in
    creating future certificates.
   </para>

   <para>
    It is also possible to create a chain of trust that includes
    intermediate certificates:
<programlisting>
# root
openssl req -new -nodes -text -out root.csr \
  -keyout root.key -subj "/CN=<replaceable>root.yourdomain.com</replaceable>"
chmod og-rwx root.key
openssl x509 -req -in root.csr -text -days 3650 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -signkey root.key -out root.crt

# intermediate
openssl req -new -nodes -text -out intermediate.csr \
  -keyout intermediate.key -subj "/CN=<replaceable>intermediate.yourdomain.com</replaceable>"
chmod og-rwx intermediate.key
openssl x509 -req -in intermediate.csr -text -days 1825 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -CA root.crt -CAkey root.key -CAcreateserial \
  -out intermediate.crt

# leaf
openssl req -new -nodes -text -out server.csr \
  -keyout server.key -subj "/CN=<replaceable>dbhost.yourdomain.com</replaceable>"
chmod og-rwx server.key
openssl x509 -req -in server.csr -text -days 365 \
  -CA intermediate.crt -CAkey intermediate.key -CAcreateserial \
  -out server.crt
</programlisting>
    <filename>server.crt</filename> and
    <filename>intermediate.crt</filename> should be concatenated
    into a certificate file bundle and stored on the server.
    <filename>server.key</filename> should also be stored on the server.
    <filename>root.crt</filename> should be stored on the client so
    the client can verify that the server's leaf certificate was signed
    by a chain of certificates linked to its trusted root certificate.
    <filename>root.key</filename> and <filename>intermediate.key</filename>
    should be stored offline for use in creating future certificates.
   </para>
  </sect2>

 </sect1>

 <sect1 id="gssapi-enc">
  <title>Secure TCP/IP Connections with GSSAPI Encryption</title>

  <indexterm zone="gssapi-enc">
   <primary>gssapi</primary>
  </indexterm>

  <para>
   <productname>PostgreSQL</productname> also has native support for
   using <acronym>GSSAPI</acronym> to encrypt client/server communications for
   increased security.  Support requires that a <acronym>GSSAPI</acronym>
   implementation (such as MIT Kerberos) is installed on both client and server
   systems, and that support in <productname>PostgreSQL</productname> is
   enabled at build time (see <xref linkend="installation"/>).
  </para>

  <sect2 id="gssapi-setup">
   <title>Basic Setup</title>

   <para>
    The <productname>PostgreSQL</productname> server will listen for both
    normal and <acronym>GSSAPI</acronym>-encrypted connections on the same TCP
    port, and will negotiate with any connecting client whether to
    use <acronym>GSSAPI</acronym> for encryption (and for authentication).  By
    default, this decision is up to the client (which means it can be
    downgraded by an attacker); see <xref linkend="auth-pg-hba-conf"/> about
    setting up the server to require the use of <acronym>GSSAPI</acronym> for
    some or all connections.
   </para>

   <para>
    When using <acronym>GSSAPI</acronym> for encryption, it is common to
    use <acronym>GSSAPI</acronym> for authentication as well, since the
    underlying mechanism will determine both client and server identities
    (according to the <acronym>GSSAPI</acronym> implementation) in any
    case.  But this is not required;
    another <productname>PostgreSQL</productname> authentication method
    can be chosen to perform additional verification.
   </para>

   <para>
    Other than configuration of the negotiation
    behavior, <acronym>GSSAPI</acronym> encryption requires no setup beyond
    that which is necessary for GSSAPI authentication.  (For more information
    on configuring that, see <xref linkend="gssapi-auth"/>.)
   </para>
  </sect2>
 </sect1>

 <sect1 id="ssh-tunnels">
  <title>Secure TCP/IP Connections with <application>SSH</application> Tunnels</title>

  <indexterm zone="ssh-tunnels">