diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
new file mode 100644
index 4e46451..d38760e
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** ldap://ldap.acme.com/cn=dbserver,cn=host
*** 7677,7682 ****
--- 7677,7686 ----
that CA would also be trusted for server certificates.
+
+ For instructions on creating certificates, see .
+
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
new file mode 100644
index a2ebd3e..989fcff
*** a/doc/src/sgml/runtime.sgml
--- b/doc/src/sgml/runtime.sgml
*************** pg_dumpall -p 5432 | psql -d postgres -p
*** 2385,2399 ****
! Creating a Self-signed Certificate
! To create a quick self-signed certificate for the server, valid for 365
days, use the following OpenSSL command,
! replacing yourdomain.com with the server's host name:
openssl req -new -x509 -days 365 -nodes -text -out server.crt \
! -keyout server.key -subj "/CN=yourdomain.com"
Then do:
--- 2385,2400 ----
! Creating Certificates
! To create a simple self-signed certificate for the server, valid for 365
days, use the following OpenSSL command,
! replacing dbhost.yourdomain.com with the
! server's host name:
openssl req -new -x509 -days 365 -nodes -text -out server.crt \
! -keyout server.key -subj "/CN=dbhost.yourdomain.com"
Then do:
*************** chmod og-rwx server.key
*** 2406,2419 ****
! A self-signed certificate can be used for testing, but a certificate
! signed by a certificate authority (CA) (either one of the
! global CAs or a local one) should be used in production
! so that clients can verify the server's identity. If all the clients
! are local to the organization, using a local CA is
! recommended.
--- 2407,2492 ----
! While a self-signed certificate can be used for testing, a certificate
! signed by a certificate authority (CA) (usually an
! enterprise-wide root CA) should be used in production.
+
+ To create a server certificate whose identity can be validated
+ by clients, first create a certificate signing request
+ (CSR) and a public/private key file:
+
+ openssl req -new -nodes -text -out root.csr \
+ -keyout root.key -subj "/CN=root.yourdomain.com"
+ chmod og-rwx root.key
+
+ Then, sign the request with the key to create a root certificate
+ authority (using the default OpenSSL
+ configuration file location on Linux):
+
+ openssl x509 -req -in root.csr -text -days 3650 \
+ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
+ -signkey root.key -out root.crt
+
+ Finally, create a server certificate signed by the new root certificate
+ authority:
+
+ openssl req -new -nodes -text -out server.csr \
+ -keyout server.key -subj "/CN=dbhost.yourdomain.com"
+ chmod og-rwx server.key
+
+ openssl x509 -req -in server.csr -text -days 365 \
+ -CA root.crt -CAkey root.key -CAcreateserial \
+ -out server.crt
+
+ server.crt and server.key
+ should be stored on the server, and root.crt should
+ be stored on the client so the client can verify that the server's leaf
+ certificate was signed by its trusted root certificate.
+ root.key should be stored offline for use in
+ creating future certificates.
+
+
+
+ It is also possible to create a chain of trust that includes
+ intermediate certificates:
+
+ # root
+ openssl req -new -nodes -text -out root.csr \
+ -keyout root.key -subj "/CN=root.yourdomain.com"
+ chmod og-rwx root.key
+ openssl x509 -req -in root.csr -text -days 3650 \
+ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
+ -signkey root.key -out root.crt
+
+ # intermediate
+ openssl req -new -nodes -text -out intermediate.csr \
+ -keyout intermediate.key -subj "/CN=intermediate.yourdomain.com"
+ chmod og-rwx intermediate.key
+ openssl x509 -req -in intermediate.csr -text -days 1825 \
+ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
+ -CA root.crt -CAkey root.key -CAcreateserial \
+ -out intermediate.crt
+
+ # leaf
+ openssl req -new -nodes -text -out server.csr \
+ -keyout server.key -subj "/CN=dbhost.yourdomain.com"
+ chmod og-rwx server.key
+ openssl x509 -req -in server.csr -text -days 365 \
+ -CA intermediate.crt -CAkey intermediate.key -CAcreateserial \
+ -out server.crt
+
+ server.crt and
+ intermediate.crt should be concatenated
+ into a certificate file bundle and stored on the server.
+ server.key should also be stored on the server.
+ root.crt should be stored on the client so
+ the client can verify that the server's leaf certificate was signed
+ by a chain of certificates linked to its trusted root certificate.
+ root.key and intermediate.key
+ should be stored offline for use in creating future certificates.
+