Обсуждение: 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 +