diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
new file mode 100644
index a2ebd3e..7f83d0c
*** a/doc/src/sgml/runtime.sgml
--- b/doc/src/sgml/runtime.sgml
*************** pg_dumpall -p 5432 | psql -d postgres -p
*** 2385,2399 ****
    </sect2>
  
    <sect2 id="ssl-certificate-creation">
!    <title>Creating a Self-signed Certificate</title>
  
     <para>
!      To create a quick self-signed certificate for the server, valid for 365
       days, use the following <productname>OpenSSL</productname> command,
!      replacing <replaceable>yourdomain.com</replaceable> with the server's host name:
  <programlisting>
  openssl req -new -x509 -days 365 -nodes -text -out server.crt \
!   -keyout server.key -subj "/CN=<replaceable>yourdomain.com</replaceable>"
  </programlisting>
      Then do:
  <programlisting>
--- 2385,2400 ----
    </sect2>
  
    <sect2 id="ssl-certificate-creation">
!    <title>Creating Certificates</title>
  
     <para>
!      To create a simple self-signed certificate for the server, valid for 365
       days, use the following <productname>OpenSSL</productname> command,
!      replacing <replaceable>dbhost.yourdomain.com</replaceable> with the
!      server's host name:
  <programlisting>
  openssl req -new -x509 -days 365 -nodes -text -out server.crt \
!   -keyout server.key -subj "/CN=<replaceable>dbhost.yourdomain.com</replaceable>"
  </programlisting>
      Then do:
  <programlisting>
*************** chmod og-rwx server.key
*** 2406,2419 ****
     </para>
  
     <para>
!     A self-signed certificate can be used for testing, but a certificate
!     signed by a certificate authority (<acronym>CA</acronym>) (either one of the
!     global <acronym>CAs</acronym> 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 <acronym>CA</acronym> is
!     recommended.
     </para>
  
    </sect2>
  
   </sect1>
--- 2407,2491 ----
     </para>
  
     <para>
!     While a self-signed certificate can be used for testing, a certificate
!     signed by a certificate authority (<acronym>CA</acronym>) (usually an
!     enterprise-wide root <acronym>CAs</acronym>) should be used in production.
!    </para>
! 
!    <para>
!     To create a server certificate whose identity can be validated
!     by clients, first create a certificate signing request
!     (<acronym>CSR</acronym>) and a public/private key file:
! <programlisting>
! openssl req -new -nodes -text -out root.csr \
!   -keyout root.key -subj "/CN=<replaceable>root.yourdomain.com</replaceable>"
! chmod og-rwx root.key
! </programlisting>
!     Then, sign the request with the the key to create a root certificate
!     authority:
! <programlisting>
! openssl x509 -req -in root.csr -text -days 3650 \
!   -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
!   -signkey root.key -out root.crt
! </programlisting>
!     Finally, create a server certificate signed by the new root certificate
!     authority:
! <programlisting>
! openssl req -new -nodes -text -out server.csr \
!   -keyout server.key -subj "/CN=<replaceable>dbhost.yourdomain.com</replaceable>"
! chmod og-rwx server.key
! 
! openssl x509 -req -in server.csr -text -days 365 \
!   -CA root.crt -CAkey root.key -CAcreateserial \
!   -out server.crt
! </programlisting>
!     <filename>server.crt</filename> and <filename>server.key</filename>
!     should be stored on the server, and <filename>root.crt</filename> should
!     be stored on the client so the client can verify that the server's leaf
!     certificate was signed by its trusted root certificate. 
!     <filename>root.key</filename> should be stored offline for use in
!     creating future certificates.
     </para>
  
+    <para>
+     It is also possible to create a chain of trust that includes
+     intermediate certificates:
+ <programlisting>
+ # root
+ openssl req -new -nodes -text -out root.csr \
+   -keyout root.key -subj "/CN=<replaceable>root.yourdomain.com</replaceable>"
+ 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=<replaceable>intermediate.yourdomain.com</replaceable>"
+ 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=<replaceable>dbhost.yourdomain.com</replaceable>"
+ chmod og-rwx server.key
+ openssl x509 -req -in server.csr -text -days 365 \
+   -CA intermediate.crt -CAkey intermediate.key -CAcreateserial \
+   -out server.crt
+ </programlisting>
+     <filename>server.crt</filename> and
+     <filename>intermediate.crt</filename> should be concatenated
+     into a certificate file bundle and stored on the server.
+     <filename>server.key</filename> should also be stored on the server.
+     <filename>root.crt</filename> 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.
+     <filename>root.key</filename> and <filename>intermediate.key</filename>
+     should be stored offline for use in creating future certificates.
+    </para>
    </sect2>
  
   </sect1>