1- <!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.285 2009/04/15 13:03:11 momjian Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.286 2009/04/24 09:43:09 mha Exp $ -->
22
33<chapter id="libpq">
44 <title><application>libpq</application> - C Library</title>
292292 <entry><literal>require</></entry>
293293 <entry>only try an <acronym>SSL</> connection</entry>
294294 </row>
295-
295+
296+ <row>
297+ <entry><literal>verify-ca</></entry>
298+ <entry>only try an <acronym>SSL</> connection, and verify that
299+ the server certificate is issued by a trusted <acronym>CA</>.
300+ </entry>
301+ </row>
302+
303+ <row>
304+ <entry><literal>verify-full</></entry>
305+ <entry>only try an <acronym>SSL</> connection, verify that
306+ the server certificate is issued by a trusted <acronym>CA</> and
307+ that the server hostname matches that in the certificate.</entry>
308+ </row>
309+
296310 </tbody>
297311 </tgroup>
298312 </table>
311325 </listitem>
312326 </varlistentry>
313327
314- <varlistentry id="libpq-connect-sslverify" xreflabel="sslverify">
315- <term><literal>sslverify</literal></term>
316- <listitem>
317- <para>
318- This option controls how libpq verifies the certificate on the
319- server when performing an <acronym>SSL</> connection. There are
320- three options: <literal>none</> disables verification completely
321- (not recommended); <literal>cert</> enables verification that
322- the server certificate chains to a known certificate
323- authority (CA); <literal>cn</> will both verify that the
324- certificate chains to a known CA and that the <literal>cn</>
325- attribute of the server certificate matches the server's
326- hostname (default).
327- </para>
328-
329- <para>
330- It is always recommended to use the <literal>cn</> value for
331- this parameter, since this is the only option that prevents
332- man-in-the-middle attacks. Note that this requires the server
333- name on the certificate to match exactly with the host name
334- used for the connection, and therefore does not support connections
335- to aliased names. It can be used with pure IP address connections
336- only if the certificate also has just the IP address in the
337- <literal>cn</> field.
338- </para>
339-
340- <para>
341- If the <literal>cn</> attribute in the certificate sent by the
342- server starts with an asterisk (<literal>*</>), it will be treated
343- as a wildcard. This wildcard can only be present at the start of
344- the value, and will match all characters <emphasis>except</> a
345- dot (<literal>.</>). This means the certificate will not match
346- subdomains.
347- </para>
348- </listitem>
349- </varlistentry>
350-
351328 <varlistentry id="libpq-connect-requiressl" xreflabel="requiressl">
352329 <term><literal>requiressl</literal></term>
353330 <listitem>
@@ -5800,16 +5777,6 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
58005777 </para>
58015778 </listitem>
58025779
5803- <listitem>
5804- <para>
5805- <indexterm>
5806- <primary><envar>PGSSLVERIFY</envar></primary>
5807- </indexterm>
5808- <envar>PGSSLVERIFY</envar> behaves the same as <xref
5809- linkend="libpq-connect-sslverify"> connection parameter.
5810- </para>
5811- </listitem>
5812-
58135780 <listitem>
58145781 <para>
58155782 <indexterm>
@@ -6162,25 +6129,60 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
61626129 file.
61636130 </para>
61646131
6132+ <sect2 id="libq-ssl-certificates">
6133+ <title>Certificate verification</title>
6134+
6135+ <para>
6136+ By default, <productname>PostgreSQL</> will not perform any validation of
6137+ the server certificate. This means that it is possible to spoof the server
6138+ identity (for example by modifying a DNS record or by taking over the server
6139+ IP address) without the client knowing. In order to prevent this,
6140+ <acronym>SSL</> certificate validation must be used.
6141+ </para>
6142+
6143+ <para>
6144+ If the parameter <literal>sslmode</> is set to <literal>verify-ca</>
6145+ libpq will verify that the server is trustworthy by checking the certificate
6146+ chain up to a trusted <acronym>CA</>. If <literal>sslmode</> is set to
6147+ <literal>verify-full</>, libpq will <emphasis>also</> verify that the server
6148+ hostname matches that of the certificate. The SSL connection will fail if
6149+ the server certificate cannot be verified. <literal>verify-full</> is
6150+ recommended in most security sensitive environments.
6151+ </para>
6152+
61656153 <para>
6166- When the <literal>sslverify</> parameter is set to <literal>cn</> or
6167- <literal>cert</>, libpq requires a trustworthy server certificate by
6168- checking the certificate chain up to a <acronym>CA</>.
6169- To allow verification, place the certificate of a trusted <acronym>CA</>
6170- in the file <filename>~/.postgresql/root.crt</> in the user's home directory.
6171- (On Microsoft Windows the file is named
6154+ In <literal>verify-full</> mode, the <literal>cn</> attribute of the
6155+ certificate is matched against the hostname. If the <literal>cn</>
6156+ attribute starts with an asterisk (<literal>*</>), it will be treated as
6157+ a wildcard, and will match all characters <emphasis>except</> a dot
6158+ (<literal>.</>). This means the certificate will not match subdomains.
6159+ If the connection is made using an IP address instead of a hostname, the
6160+ IP address will be matched (without doing any DNS lookups).
6161+ </para>
6162+
6163+ <para>
6164+ To allow verification, the certificate of a trusted <acronym>CA</> must be
6165+ placed in the file <filename>~/.postgresql/root.crt</> in the user's home
6166+ directory. (On Microsoft Windows the file is named
61726167 <filename>%APPDATA%\postgresql\root.crt</filename>.)
6173- <application>libpq</application> will then verify that the server's
6174- certificate is signed by one of the trusted certificate authorities.
6175- The SSL connection will fail if the server certificate cannot be verified.
6168+ </para>
6169+
6170+ <para>
61766171 Certificate Revocation List (CRL) entries are also checked
61776172 if the file <filename>~/.postgresql/root.crl</filename> exists
61786173 (<filename>%APPDATA%\postgresql\root.crl</filename> on Microsoft
61796174 Windows).
6175+ </para>
6176+
6177+ <para>
61806178 The location of the root certificate store and the CRL can be overridden
61816179 by the connection parameters <literal>sslrootcert</> and <literal>sslcrl</>
61826180 or the environment variables <envar>PGSSLROOTCERT</> and <envar>PGSSLCRL</>.
61836181 </para>
6182+ </sect2>
6183+
6184+ <sect2 id="libpq-ssl-clientcert">
6185+ <title>Client certificates</title>
61846186
61856187 <para>
61866188 If the server requests a trusted client certificate,
@@ -6201,6 +6203,9 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
62016203 environment variables <envar>PGSSLCERT</> and <envar>PGSSLKEY</>.
62026204 </para>
62036205
6206+ </sect2>
6207+ <sect2 id="libpq-ssl-fileusage">
6208+ <title>SSL File Usage</title>
62046209 <table id="libpq-ssl-file-usage">
62056210 <title>Libpq/Client SSL File Usage</title>
62066211 <tgroup cols="3">
@@ -6243,6 +6248,10 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
62436248 </tbody>
62446249 </tgroup>
62456250 </table>
6251+ </sect2>
6252+
6253+ <sect2 id="libpq-ssl-initialize">
6254+ <title>SSL library initialization</title>
62466255
62476256 <para>
62486257 If your application initializes <literal>libssl</> and/or
@@ -6330,6 +6339,7 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
63306339 </varlistentry>
63316340 </variablelist>
63326341 </para>
6342+ </sect2>
63336343
63346344 </sect1>
63356345
0 commit comments