public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Michael Paquier <[email protected]>
Cc: PostgreSQL-documentation <[email protected]>
Cc: Stephen Frost <[email protected]>
Cc: David Steele <[email protected]>
Subject: Re: Correction of intermediate certificate handling
Date: Wed, 17 Jan 2018 21:00:17 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On Thu, Jan 18, 2018 at 10:25:03AM +0900, Michael Paquier wrote:
> On Wed, Jan 17, 2018 at 07:34:42AM -0500, Bruce Momjian wrote:
> > Yes, I was not happy about that either. I was afraid that pound-sign
> > comments would look like root prompts but I just added them and they
> > look fine. Updated patch attached, with some expiration and wording
> > adjustments. There is also a new paragraph at the end explaining where
> > to place the files.
>
> Thanks, that's a net improvement. So +1 for this version.
>
> + enterprise-wide root <acronym>CAs</acronym>) should be used in production.
> Nit here. CA should not be plural.
>
> +</programlisting>
> + Then, sign the request with the the key to create a root certificate
> + authority:
> You still have a "the the" here.
>
> /etc/ssl/openssl.cnf is not available on macos or Windows, which can
> lead to a bit of confusion as I would imagine that people would
> copy/paste such commands when testing things. Perhaps it would be worth
> mentioning that this path is proper to usual Linux distributions (I can
> see it at least on ArchLinux and Debian), with a reference to this
> OpenSSL link:
> https://www.openssl.org/docs/manmaster/man5/config.html
>
> There is as well a set of tiny configuration files in src/test/ssl.
One odd thing about the configuration file is that you don't need to
modify it, but you do need to specify it for that command.
Fixed patch attached.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Attachments:
[text/x-diff] openssl.diff (6.1K, 2-openssl.diff)
download | inline diff:
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.
</para>
+ <para>
+ For instructions on creating certificates, see <xref
+ linkend="ssl-certificate-creation"/>.
+ </para>
</sect2>
<sect2 id="libpq-ssl-protection">
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 ****
</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,2492 ----
</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>"
+ 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>
view thread (16+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Correction of intermediate certificate handling
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox