diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
new file mode 100644
index a2ebd3e..dca113b
*** a/doc/src/sgml/runtime.sgml
--- b/doc/src/sgml/runtime.sgml
*************** pg_dumpall -p 5432 | psql -d postgres -p
*** 2385,2394 ****
! 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:
--- 2385,2394 ----
! Creating Certificates
! To create a simple self-signed certificate for the server, valid for 365
days, use the following OpenSSL command,
replacing yourdomain.com with the server's host name:
*************** 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.
--- 2406,2476 ----
! While a self-signed certificate can be used for testing, a certificate
! signed by a certificate authority (CA) (usually an
! enterprise-wide root CAs) should be used in production.
+
+ To create a server certificate whose identity can be validated
+ by clients, first create a public/private key pair and certificate
+ signing request (CSR):
+
+ 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 the private key to create a root
+ certificate authority:
+
+ openssl x509 -req -in root.csr -text -days 365 \
+ -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.
+
+
+
+ It is also possible to create a chain of trust that includes
+ intermediate certificates:
+
+ 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 365 \
+ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
+ -signkey root.key -out root.crt
+
+ 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 365 \
+ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
+ -CA root.crt -CAkey root.key -CAcreateserial \
+ -out intermediate.crt
+
+ 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
+
+