diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
new file mode 100644
index 4e46451..801b033
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** ldap://ldap.acme.com/cn=dbserver,cn=host
*** 7601,7613 ****
! To allow server certificate verification, the certificate(s) of one or more
! trusted CAs must be
! placed in the file ~/.postgresql/root.crt in the user's home
! directory. If intermediate CAs appear in
! root.crt, the file must also contain certificate
! chains to their root CAs. (On Microsoft Windows the file is named
! %APPDATA%\postgresql\root.crt.)
--- 7601,7613 ----
! To allow server certificate verification, one or more root certificates
! must be placed in the file ~/.postgresql/root.crt
! in the user's home directory. (On Microsoft Windows the file is named
! %APPDATA%\postgresql\root.crt.) Intermediate
! certificates should also be added to the file if they are needed to link
! the certificate chain sent by the server to the root certificates
! stored on the client.
*************** ldap://ldap.acme.com/cn=dbserver,cn=host
*** 7660,7682 ****
! In some cases, the client certificate might be signed by an
! intermediate
certificate authority, rather than one that is
! directly trusted by the server. To use such a certificate, append the
! certificate of the signing authority to the postgresql.crt
! file, then its parent authority's certificate, and so on up to a certificate
! authority, root
or intermediate
, that is trusted by
! the server, i.e. signed by a certificate in the server's root CA file
! ().
!
!
!
! Note that the client's ~/.postgresql/root.crt lists the top-level CAs
! 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
! that CA would also be trusted for server certificates.
-
--- 7660,7672 ----
! The first certificate in postgresql.crt must be the
! clients's certificate because it must match the client's private key.
! The certificates of intermediate
certificate authorities
! can be optionally appended to the file. Doing this avoids requiring
! the intermediate certificates to be stored on the server ().
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
new file mode 100644
index a2ebd3e..6352d53
*** a/doc/src/sgml/runtime.sgml
--- b/doc/src/sgml/runtime.sgml
*************** pg_dumpall -p 5432 | psql -d postgres -p
*** 2247,2286 ****
! In some cases, the server certificate might be signed by an
! intermediate
certificate authority, rather than one that is
! directly trusted by clients. To use such a certificate, append the
! certificate of the signing authority to the server.crt file,
! then its parent authority's certificate, and so on up to a certificate
! authority, root
or intermediate
, that is trusted by
! clients, i.e. signed by a certificate in the clients'
! root.crt files.
Using Client Certificates
! To require the client to supply a trusted certificate, place
! certificates of the certificate authorities (CAs)
! you trust in a file named root.crt in the data
directory, set the parameter in
! postgresql.conf to root.crt,
! and add the authentication option clientcert=1 to the
! appropriate hostssl line(s) in pg_hba.conf.
! A certificate will then be requested from the client during
! SSL connection startup. (See for a
! 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
certificate authorities.
! If intermediate CAs appear in
! root.crt, the file must also contain certificate
! chains to their root CAs. Certificate Revocation List
! (CRL) entries
! are also checked if the parameter is set.
(See
--- 2247,2292 ----
! The first certificate in server.crt must be the
! server's certificate because it must match the server's private key.
! The certificates of intermediate
certificate authorities
! can also be appended to the file. Doing this avoids the necessity of
! storing intermediate certificates on clients, assuming the root and
! intermediate certificates were created with v3_ca
! extensions. This allows easier expiration of intermediate certificates.
!
!
!
! It is not necessary to add the root certificate to
! server.crt. Instead, clients must have the root
! certificate of the server's certificate chain.
Using Client Certificates
! To require the client to supply a trusted certificate,
! place certificates of the root certificate authorities
! (CAs) you trust in a file in the data
directory, set the parameter in
! postgresql.conf to the new file name, and add the
! authentication option clientcert=1 to the appropriate
! hostssl line(s) in pg_hba.conf.
! A certificate will then be requested from the client during SSL
! connection startup. (See for a 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
certificate authorities.
! Intermediate certificates that chain up to existing root certificates
! can also appear in the file if
! you wish to avoid storing them on clients (assuming the root and
! intermediate certificates were created with v3_ca
! extensions). Certificate Revocation List (CRL) entries are also
! checked if the parameter is set.
(See
*************** pg_dumpall -p 5432 | psql -d postgres -p
*** 2297,2310 ****
- Note that the server's root.crt lists the top-level
- 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
- that CA would also be trusted for client certificates.
-
-
-
If you are setting up client certificates, you may wish to use
the cert authentication method, so that the certificates
control user authentication as well as providing connection security.
--- 2303,2308 ----