trusted <acronym>CA</acronym> and that the requested server host name
            matches that in the certificate
           </para>
          </listitem>
         </varlistentry>
        </variablelist>

        See <xref linkend="libpq-ssl"/> for a detailed description of how
        these options work.
       </para>

       <para>
        <literal>sslmode</literal> is ignored for Unix domain socket
        communication.
        If <productname>PostgreSQL</productname> is compiled without SSL support,
        using options <literal>require</literal>, <literal>verify-ca</literal>, or
        <literal>verify-full</literal> will cause an error, while
        options <literal>allow</literal> and <literal>prefer</literal> will be
        accepted but <application>libpq</application> will not actually attempt
        an <acronym>SSL</acronym>
        connection.<indexterm><primary>SSL</primary><secondary
        sortas="libpq">with libpq</secondary></indexterm>
       </para>

       <para>
        Note that if <acronym>GSSAPI</acronym> encryption is possible,
        that will be used in preference to <acronym>SSL</acronym>
        encryption, regardless of the value of <literal>sslmode</literal>.
        To force use of <acronym>SSL</acronym> encryption in an
        environment that has working <acronym>GSSAPI</acronym>
        infrastructure (such as a Kerberos server), also set
        <literal>gssencmode</literal> to <literal>disable</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="libpq-connect-requiressl" xreflabel="requiressl">
      <term><literal>requiressl</literal></term>
      <listitem>
       <para>
        This option is deprecated in favor of the <literal>sslmode</literal>
        setting.
       </para>

       <para>
        If set to 1, an <acronym>SSL</acronym> connection to the server
        is required (this is equivalent to <literal>sslmode</literal>
        <literal>require</literal>).  <application>libpq</application> will then refuse
        to connect if the server does not accept an
        <acronym>SSL</acronym> connection.  If set to 0 (default),
        <application>libpq</application> will negotiate the connection type with
        the server (equivalent to <literal>sslmode</literal>
        <literal>prefer</literal>).  This option is only available if
        <productname>PostgreSQL</productname> is compiled with SSL support.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="libpq-connect-sslnegotiation" xreflabel="sslnegotiation">
      <term><literal>sslnegotiation</literal></term>
      <listitem>
       <para>
        This option controls how SSL encryption is negotiated with the server,
        if SSL is used. In the default <literal>postgres</literal> mode, the
        client first asks the server if SSL is supported. In
        <literal>direct</literal> mode, the client starts the standard SSL
        handshake directly after establishing the TCP/IP connection. Traditional
        <productname>PostgreSQL</productname> protocol negotiation is the most
        flexible with different server configurations. If the server is known
        to support direct <acronym>SSL</acronym> connections then the latter
        requires one fewer round trip reducing connection latency and also
        allows the use of protocol agnostic SSL network tools. The direct SSL
        option was introduced in <productname>PostgreSQL</productname> version
        17.
       </para>

        <variablelist>
         <varlistentry>
          <term><literal>postgres</literal></term>
          <listitem>
           <para>
             perform <productname>PostgreSQL</productname> protocol
             negotiation. This is the default if the option is not provided.
           </para>
          </listitem>
         </varlistentry>

         <varlistentry>
          <term><literal>direct</literal></term>
          <listitem>
           <para>