start, the server will
    refuse to start.  But if an error is detected during a configuration
    reload, the files are ignored and the old SSL configuration continues to
    be used.  On <systemitem class="osname">Windows</systemitem> systems, if an error in
    these files is detected at backend start, that backend will be unable to
    establish an SSL connection.  In all these cases, the error condition is
    reported in the server log.
   </para>
  </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
</programlisting>
    because the server will reject the file if its permissions are more
    liberal than this.
    For more details on how to create your server private key and
    certificate, refer to the <productname>OpenSSL</productname> documentation.
   </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>CA</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 key to create a root certificate
    authority (using the default <productname>OpenSSL</productname>
    configuration file location on <productname>Linux</productname>):
<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>"