Home • Explore • Blog • CI
☰



postgresql
11th chunk of `doc/src/sgml/client-auth.sgml`
e949df67c0cb0fccb6c8c7be507c1fada828b7f200f02b980000000100000fa9
 specified in any <literal>hostssl</literal> record.
       This option can be set to <literal>verify-ca</literal> or
       <literal>verify-full</literal>. Both options require the client
       to present a valid (trusted) SSL certificate, while
       <literal>verify-full</literal> additionally enforces that the
       <literal>cn</literal> (Common Name) in the certificate matches
       the username or an applicable mapping.
       This behavior is similar to the <literal>cert</literal> authentication
       method (see <xref linkend="auth-cert"/>) but enables pairing
       the verification of client certificates with any authentication
       method that supports <literal>hostssl</literal> entries.
      </para>
      <para>
       On any record using client certificate authentication (i.e. one
       using the <literal>cert</literal> authentication method or one
       using the <literal>clientcert</literal> option), you can specify
       which part of the client certificate credentials to match using
       the <literal>clientname</literal> option. This option can have one
       of two values. If you specify <literal>clientname=CN</literal>, which
       is the default, the username is matched against the certificate's
       <literal>Common Name (CN)</literal>. If instead you specify
       <literal>clientname=DN</literal> the username is matched against the
       entire <literal>Distinguished Name (DN)</literal> of the certificate.
       This option is probably best used in conjunction with a username map.
       The comparison is done with the <literal>DN</literal> in
       <ulink url="https://datatracker.ietf.org/doc/html/rfc2253">RFC 2253</ulink>
       format. To see the <literal>DN</literal> of a client certificate
       in this format, do
<programlisting>
openssl x509 -in myclient.crt -noout -subject -nameopt RFC2253 | sed "s/^subject=//"
</programlisting>
        Care needs to be taken when using this option, especially when using
        regular expression matching against the <literal>DN</literal>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>include</literal></term>
     <listitem>
      <para>
       This line will be replaced by the contents of the given file.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>include_if_exists</literal></term>
     <listitem>
      <para>
       This line will be replaced by the content of the given file if the
       file exists. Otherwise, a message is logged to indicate that the file
       has been skipped.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>include_dir</literal></term>
     <listitem>
      <para>
       This line will be replaced by the contents of all the files found in
       the directory, if they don't start with a <literal>.</literal> and end
       with <literal>.conf</literal>, processed in file name order (according
       to C locale rules, i.e., numbers before letters, and uppercase letters
       before lowercase ones).
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   Files included by <literal>@</literal> constructs are read as lists of names,
   which can be separated by either whitespace or commas.  Comments are
   introduced by <literal>#</literal>, just as in
   <filename>pg_hba.conf</filename>, and nested <literal>@</literal> constructs are
   allowed.  Unless the file name following <literal>@</literal> is an absolute
   path, it is taken to be relative to the directory containing the
   referencing file.
  </para>

  <para>
   Since the <filename>pg_hba.conf</filename> records are examined
   sequentially for each connection attempt, the order of the records is
   significant. Typically, earlier records will have tight connection
   match parameters and weaker authentication methods, while later
   records will have looser match parameters and stronger authentication
Title: PostgreSQL Configuration File Directives
Summary
The PostgreSQL configuration file supports various directives, including options for client certificate authentication, such as verifying the Common Name or Distinguished Name in the certificate. The file also allows for inclusion of other files using the `include`, `include_if_exists`, and `include_dir` directives. The order of records in the configuration file is significant, with earlier records typically having tighter connection match parameters and weaker authentication methods.