Subject: Creating Certificates

From: Tatsuo Ishii <[email-masked]>
Date: Sat, 06 Oct 2018 08:17:04 +0900 (JST)

In "18.9.3. Creating Certificates",

------------------------------------------------------------------
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
------------------------------------------------------------------

For me it seesm the two-step procedure can be replaced with following
one command:

openssl req -new -x509 -nodes -text -days 3650 \
  -config /etc/ssl/openssl.cnf -extensions v3_ca \
  -out root.crt -keyout root.key -subj "/CN=root.yourdomain.com"

Is there any reaon why our doc recommend the two-step procedure?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

---

From: Tatsuo Ishii <[email-masked]>
Date: Sat, 06 Oct 2018 18:46:54 +0900 (JST)

After sending below to pgsql-docs, I noticed if I follow the step
described in the doc[1], generated root.crt lacks below.

        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                3B:16:EA:86:0B:7C:E4:7A:16:F2:4E:54:F5:9C:0E:0F:38:02:8C:CF
            X509v3 Authority Key Identifier: 
                keyid:3B:16:EA:86:0B:7C:E4:7A:16:F2:4E:54:F5:9C:0E:0F:38:02:8C:CF

            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption

>   -out root.crt -keyout root.key -subj "/CN=root.yourdomain.com"

I wonder if this is normal or not.

Best regards,

From: Tatsuo Ishii <[email-masked]>
Subject: Creating Certificates
Date: Sat, 06 Oct 2018 08:17:04 +0900 (JST)
Message-ID: <[email-masked]>

> In "18.9.3. Creating Certificates",
[1]
>   -signkey root.key -out root.crt
[2]

---

From: Andrew Dunstan <[email-masked]>
Date: Sat, 6 Oct 2018 10:47:30 -0400

> I wonder if this is normal or not.

It will in fact be in the certificate:

    andrew@ad-c7:tmp $ openssl req -new -nodes  -out root.csr -keyout
    root.key -subj "/CN=root.yourdomain.com"
    Generating a 2048 bit RSA private key
    ...+++
    .......................+++
    writing new private key to 'root.key'
    -----
    andrew@ad-c7:tmp $ openssl x509 -req -in root.csr -days 3650
    -extfile /etc/pki/tls/openssl.cnf -extensions v3_ca -signkey
    root.key -out root.crt
    Signature ok
    subject=/CN=root.yourdomain.com
    Getting Private key
    andrew@ad-c7:tmp $ openssl x509 -in root.crt -noout -text
    Certificate:
         Data:
             Version: 3 (0x2)
             Serial Number:
                 b3:cf:16:ad:94:fa:69:d6
         Signature Algorithm: sha256WithRSAEncryption
             Issuer: CN=root.yourdomain.com
             Validity
                 Not Before: Oct  6 14:44:05 2018 GMT
                 Not After : Oct  3 14:44:05 2028 GMT
             Subject: CN=root.yourdomain.com
             Subject Public Key Info:
                 Public Key Algorithm: rsaEncryption
                     Public-Key: (2048 bit)
                     Modulus:
                         00:ea:37:82:84:45:b2:21:15:a6:bc:4c:00:9f:15:
                         c4:8c:c2:0c:14:a2:1f:55:3b:5b:33:45:80:a4:47:
                         c1:4b:31:f6:2d:a3:ff:e6:eb:fe:05:4a:8f:6d:24:
                         ec:dc:ab:cf:b0:30:38:1e:1a:ba:32:31:98:e1:31:
                         73:ab:7f:0c:aa:5c:33:f8:68:b1:c2:8b:eb:2a:60:
                         88:4d:77:d9:65:b3:08:10:dd:3a:de:3b:ff:88:c9:
                         f7:6d:e1:0a:8f:e0:cd:ac:67:40:76:0c:50:d3:ee:
                         63:9b:23:25:87:ce:a4:2f:a4:46:4c:dc:8f:d6:98:
                         55:75:bb:79:d2:21:57:bc:b3:72:fb:d0:7e:4e:f5:
                         2d:97:34:82:89:4a:70:59:87:5e:e1:8a:5e:ce:15:
                         ab:a1:83:c6:be:75:b2:70:12:88:87:89:4d:a1:ca:
                         11:bf:3f:2e:0d:0e:e6:64:cf:8b:44:8a:d7:ba:15:
                         66:85:16:87:6b:e4:22:cc:70:80:9a:a6:ef:8a:bf:
                         e9:b5:0a:11:aa:b7:3f:91:ad:a1:37:5e:7e:29:a5:
                         6e:7d:e9:1c:c4:53:23:fd:cf:e0:79:f9:eb:98:96:
                         7d:38:10:78:d3:5b:c5:49:1f:76:c3:d6:2c:bb:00:
                         6b:19:b1:1f:6f:d4:3d:41:85:34:c1:72:48:59:b1:
                         0e:49
                     Exponent: 65537 (0x10001)
             X509v3 extensions:
                 X509v3 Subject Key Identifier:
    CD:9F:99:94:4E:3E:1D:B7:66:0D:65:6A:6E:C5:16:A8:04:20:16:6E
                 X509v3 Authority Key Identifier:
    keyid:CD:9F:99:94:4E:3E:1D:B7:66:0D:65:6A:6E:C5:16:A8:04:20:16:6E

                 X509v3 Basic Constraints:
                     CA:TRUE
         Signature Algorithm: sha256WithRSAEncryption
              e7:9d:de:79:cf:c4:ce:fd:10:6c:47:3c:b1:75:0a:5b:a5:c8:
              5a:36:63:b6:d5:46:7a:f3:3f:6a:e5:4f:46:a7:25:05:6c:d3:
              14:1e:90:73:f1:8c:46:a8:ed:c3:da:34:c2:25:09:79:39:7f:
              23:9d:43:5e:a9:2b:8e:34:d2:da:fa:c2:b4:76:0a:3b:26:14:
              c6:72:3b:df:e5:f0:0c:27:48:ab:4a:72:74:f4:d5:31:a4:4d:
              9e:f9:fa:45:f8:50:5b:81:59:bc:22:c7:9f:dc:01:fe:29:41:
              40:ff:6b:a1:82:e8:50:11:92:60:2c:e2:3b:32:9f:cd:f4:d0:
              dc:04:96:5a:18:7d:86:9b:0c:81:d5:aa:14:2b:c2:c1:80:09:
              b3:05:37:87:62:fe:36:c8:5e:28:8e:fa:6a:56:00:fa:85:6f:
              28:f1:75:1b:1b:62:9e:36:c7:ad:ec:fd:05:e0:a9:9f:b2:29:
              e5:0b:5e:fc:9f:5a:18:dd:4f:c6:ed:24:a3:a0:6b:35:b0:de:
              f3:ab:e5:42:e6:ae:9b:c1:e1:70:66:64:5c:46:86:1b:ad:a8:
              e0:4b:47:28:37:e6:ec:99:8f:e4:a9:06:0d:53:a7:5b:7c:c2:
              5d:b4:d8:14:aa:10:d9:4e:6a:1a:6e:1c:7f:2e:3c:2a:61:73:
              fd:04:cb:c1

I'm not opposed to simplifying the instructions, however.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

---

From: Tatsuo Ishii <[email-masked]>
Date: Sun, 07 Oct 2018 06:51:59 +0900 (JST)

> It will in fact be in the certificate:

Oh, ok. That makes sense. Thanks for the explanation.

Best regards,

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 13 Oct 2018 14:38:24 -0400

On Sat, Oct  6, 2018 at 08:17:04AM +0900, Tatsuo Ishii wrote:
> Is there any reason why our doc recommend the two-step procedure?

This was changed as part of this commit:

	commit 815f84aa166de294b80e80cc456b79128592720e
	Author: Bruce Momjian <[email-masked]>
	Date:   Sat Jan 20 21:47:02 2018 -0500
	
	    doc:  update intermediate certificate instructions
	
	    Document how to properly create root and intermediate certificates using
	    v3_ca extensions and where to place intermediate certificates so they
	    are properly transferred to the remote side with the leaf certificate to
	    link to the remote root certificate.  This corrects docs that used to
	    say that intermediate certificates must be stored with the root
	    certificate.
	
	    Also add instructions on how to create root, intermediate, and leaf
	    certificates.
	
	    Discussion: https://postgr.es/m/[email-masked]
	
	    Reviewed-by: Michael Paquier
	
	    Backpatch-through: 9.3

The reason I did this in two steps was so I could explain each step
independently, and because the next paragraph, "create a server
certificate signed by the new root certificate authority", also requires
two steps.  My goal was that the first command in each example creates
the CSR and public key pair, and the second command signs it.  If the
first example uses only one command, and the second example needs to use
two commands, and it appears more complex.

I guess we could show the single-command example as an alternative, but
that seems more complex too.

-- 
  Bruce Momjian  <[email-masked]>        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 +

---

From: Tatsuo Ishii <[email-masked]>
Date: Tue, 16 Oct 2018 11:45:53 +0900 (JST)

> I'm not opposed to simplifying the instructions, however.

Ok, attached is a proposal to simplify the instructions.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 8d9d40664b..23f080eeab 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -2426,21 +2426,15 @@ chmod og-rwx server.key
    </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:
+    To create a server certificate whose identity can be validated by
+    clients, create a root certificate authority (using the
+    default <productname>OpenSSL</productname> configuration file location
+    on <productname>Linux</productname>):
 <programlisting>
-openssl req -new -nodes -text -out root.csr \
-  -keyout root.key -subj "/CN=<replaceable>root.yourdomain.com</replaceable>"
+openssl req -new -x509 -nodes -text -days 3650 \
+  -config /etc/ssl/openssl.cnf -extensions v3_ca \
+  -out root.crt -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:

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 15 Oct 2018 22:49:29 -0400

> Ok, attached is a proposal to simplify the instructions.

I am against this simplification for the reasons I stated in this
thread.

---------------------------------------------------------------------------

---

From: Magnus Hagander <[email-masked]>
Date: Tue, 16 Oct 2018 14:02:48 +0200

> I am against this simplification for the reasons I stated in this

+1. While simpler, this is not necessarily better. It's a complicated
topic, needs careful instructions.

Another option could be to have both -- that is, have the separate steps,
but then a part that says "or you can combine the two steps into a single
command like abcdeef". (Which I think Bruce also suggested in an earlier
mail, if I understood what he meant)

//Magnus

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 16 Oct 2018 10:06:11 -0400

On Tue, Oct 16, 2018 at 02:02:48PM +0200, Magnus Hagander wrote:
> +1. While simpler, this is not necessarily better. It's a complicated topic,
> needs careful instructions.
> 
> Another option could be to have both -- that is, have the separate steps, but
> then a part that says "or you can combine the two steps into a single command
> like abcdeef". (Which I think Bruce also suggested in an earlier mail, if I
> understood what he meant)

Yes, we can show the first two steps also as a single command, if that
is desired.  I don't think the second two steps can be combined in a
single command.