Thread: Re: 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]
> 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
>
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
> 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:
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 +