Creating Certificates

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

This is present if I use command[2]:

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"

I wonder if this is normal or not.

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 <ishii@sraoss.co.jp>
Subject: Creating Certificates
Date: Sat, 06 Oct 2018 08:17:04 +0900 (JST)
Message-ID: <20181006.081704.1372328430253415862.t-ishii@sraoss.co.jp>

In "18.9.3. Creating Certificates",

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

[1]:

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:

[2]:

On 10/06/2018 05:46 AM, Tatsuo Ishii wrote:

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

This is present if I use command[2]:

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"

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

It will in fact be in the certificate:

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

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

On Sat, Oct 6, 2018 at 08:17:04AM +0900, Tatsuo Ishii wrote:

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 reason why our doc recommend the two-step procedure?

This was changed as part of this commit:

commit 815f84aa166de294b80e80cc456b79128592720e
Author: Bruce Momjian <bruce@momjian.us>
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: /messages/by-id/20180116002238.GC12724@momjian.us

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 <bruce@momjian.us> 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 +

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

On Tue, Oct 16, 2018 at 11:45:53AM +0900, Tatsuo Ishii wrote:

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

Ok, attached is a proposal to simplify the instructions.

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

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

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:

--
Bruce Momjian <bruce@momjian.us> 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 +

On Tue, Oct 16, 2018 at 4:49 AM Bruce Momjian <bruce@momjian.us> wrote:

On Tue, Oct 16, 2018 at 11:45:53AM +0900, Tatsuo Ishii wrote:

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

Ok, attached is a proposal to simplify the instructions.

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

+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

On Tue, Oct 16, 2018 at 02:02:48PM +0200, Magnus Hagander wrote:

On Tue, Oct 16, 2018 at 4:49 AM Bruce Momjian <bruce@momjian.us> wrote:

On Tue, Oct 16, 2018 at 11:45:53AM +0900, Tatsuo Ishii wrote:

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

Ok, attached is a proposal to simplify the instructions.

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

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

--
Bruce Momjian <bruce@momjian.us> 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 +