mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: clarify SSL certificate authority chain docs

Browse Source 
Previously, the requirements of how intermediate certificates were
handled and their chain to root certificates was unclear.
This commit is contained in:
Bruce Momjian 2013-12-06 09:42:08 -05:00
parent 312bde3d40
commit fa4add50c4
2 changed files with 20 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/src/sgml/libpq.sgml
View File

@ -7122,7 +7122,9 @@ ldap://ldap.acme.com/cn=dbserver,cn=hosts?pgconnectinfo?base?(objectclass=*)
To allow server certificate verification, the certificate(s) of one or more To allow server certificate verification, the certificate(s) of one or more
trusted <acronym>CA</>s must be trusted <acronym>CA</>s must be
placed in the file <filename>~/.postgresql/root.crt</> in the user's home placed in the file <filename>~/.postgresql/root.crt</> in the user's home
directory. (On Microsoft Windows the file is named directory. If intermediate <acronym>CA</>s appear in
<filename>root.crt</filename>, the file must also contain certificate
chains to their root <acronym>CA</>s. (On Microsoft Windows the file is named
<filename>%APPDATA%\postgresql\root.crt</filename>.) <filename>%APPDATA%\postgresql\root.crt</filename>.)
</para> </para>
@ -7180,15 +7182,15 @@ ldap://ldap.acme.com/cn=dbserver,cn=hosts?pgconnectinfo?base?(objectclass=*)
<quote>intermediate</> certificate authority, rather than one that is <quote>intermediate</> certificate authority, rather than one that is
directly trusted by the server. To use such a certificate, append the directly trusted by the server. To use such a certificate, append the
certificate of the signing authority to the <filename>postgresql.crt</> certificate of the signing authority to the <filename>postgresql.crt</>
file, then its parent authority's certificate, and so on up to a file, then its parent authority's certificate, and so on up to a certificate
<quote>root</> authority that is trusted by the server. The root authority, <quote>root</> or <quote>intermediate</>, that is trusted by
certificate should be included in every case where the server, i.e. signed by a certificate in the server's
<filename>postgresql.crt</> contains more than one certificate. <filename>root.crt</filename> file.
</para> </para>
<para> <para>
Note that <filename>root.crt</filename> lists the top-level CAs that are Note that the client's <filename>~/.postgresql/root.crt</> lists the top-level CAs
considered trusted for signing server certificates. In principle it need that are considered trusted for signing server certificates. In principle it need
not list the CA that signed the client's certificate, though in most cases not list the CA that signed the client's certificate, though in most cases
that CA would also be trusted for server certificates. that CA would also be trusted for server certificates.
</para> </para>

18
doc/src/sgml/runtime.sgml
View File

@ -1986,10 +1986,10 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
<quote>intermediate</> certificate authority, rather than one that is <quote>intermediate</> certificate authority, rather than one that is
directly trusted by clients. To use such a certificate, append the directly trusted by clients. To use such a certificate, append the
certificate of the signing authority to the <filename>server.crt</> file, certificate of the signing authority to the <filename>server.crt</> file,
then its parent authority's certificate, and so on up to a <quote>root</> then its parent authority's certificate, and so on up to a certificate
authority that is trusted by the clients. The root certificate should authority, <quote>root</> or <quote>intermediate</>, that is trusted by
be included in every case where <filename>server.crt</> contains more than clients, i.e. signed by a certificate in the clients'
one certificate. <filename>root.crt</filename> files.
</para> </para>
<sect2 id="ssl-client-certificates"> <sect2 id="ssl-client-certificates">
@ -2008,7 +2008,10 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
SSL connection startup. (See <xref linkend="libpq-ssl"> for a SSL connection startup. (See <xref linkend="libpq-ssl"> for a
description of how to set up certificates on the client.) The server will description of how to set up certificates on the client.) The server will
verify that the client's certificate is signed by one of the trusted verify that the client's certificate is signed by one of the trusted
certificate authorities. Certificate Revocation List (CRL) entries certificate authorities. If intermediate <acronym>CA</>s appear in
<filename>root.crt</filename>, the file must also contain certificate
chains to their root <acronym>CA</>s. Certificate Revocation List
(CRL) entries
are also checked if the parameter <xref linkend="guc-ssl-crl-file"> is set. are also checked if the parameter <xref linkend="guc-ssl-crl-file"> is set.
<!-- If this URL changes replace it with a URL to www.archive.org. --> <!-- If this URL changes replace it with a URL to www.archive.org. -->
(See <ulink (See <ulink
@ -2026,8 +2029,9 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
</para> </para>
<para> <para>
Note that <filename>root.crt</filename> lists the top-level CAs that are Note that the server's <filename>root.crt</filename> lists the top-level
considered trusted for signing client certificates. In principle it need CAs that are considered trusted for signing client certificates.
In principle it need
not list the CA that signed the server's certificate, though in most cases not list the CA that signed the server's certificate, though in most cases
that CA would also be trusted for client certificates. that CA would also be trusted for client certificates.
</para> </para>