public inbox for [email protected]
help / color / mirror / Atom feedCreating Certificates
9+ messages / 4 participants
[nested] [flat]
* Creating Certificates
@ 2018-10-05 23:17 Tatsuo Ishii <[email protected]>
2018-10-06 09:46 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-13 18:38 ` Re: Creating Certificates Bruce Momjian <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Tatsuo Ishii @ 2018-10-05 23:17 UTC (permalink / raw)
To: pgsql-docs
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Creating Certificates
2018-10-05 23:17 Creating Certificates Tatsuo Ishii <[email protected]>
@ 2018-10-06 09:46 ` Tatsuo Ishii <[email protected]>
2018-10-06 14:47 ` Re: Creating Certificates Andrew Dunstan <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Tatsuo Ishii @ 2018-10-06 09:46 UTC (permalink / raw)
To: [email protected]
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 <[email protected]>
Subject: Creating Certificates
Date: Sat, 06 Oct 2018 08:17:04 +0900 (JST)
Message-ID: <[email protected]>
> 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
>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Creating Certificates
2018-10-05 23:17 Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 09:46 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
@ 2018-10-06 14:47 ` Andrew Dunstan <[email protected]>
2018-10-06 21:51 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-16 02:45 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Andrew Dunstan @ 2018-10-06 14:47 UTC (permalink / raw)
To: Tatsuo Ishii <[email protected]>; [email protected]
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Creating Certificates
2018-10-05 23:17 Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 09:46 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 14:47 ` Re: Creating Certificates Andrew Dunstan <[email protected]>
@ 2018-10-06 21:51 ` Tatsuo Ishii <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Tatsuo Ishii @ 2018-10-06 21:51 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
> 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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Creating Certificates
2018-10-05 23:17 Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 09:46 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 14:47 ` Re: Creating Certificates Andrew Dunstan <[email protected]>
@ 2018-10-16 02:45 ` Tatsuo Ishii <[email protected]>
2018-10-16 02:49 ` Re: Creating Certificates Bruce Momjian <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Tatsuo Ishii @ 2018-10-16 02:45 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
> 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
Attachments:
[text/x-patch] creating-certificates.diff (1.5K, 2-creating-certificates.diff)
download | inline diff:
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:
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Creating Certificates
2018-10-05 23:17 Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 09:46 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 14:47 ` Re: Creating Certificates Andrew Dunstan <[email protected]>
2018-10-16 02:45 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
@ 2018-10-16 02:49 ` Bruce Momjian <[email protected]>
2018-10-16 12:02 ` Re: Creating Certificates Magnus Hagander <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Bruce Momjian @ 2018-10-16 02:49 UTC (permalink / raw)
To: Tatsuo Ishii <[email protected]>; +Cc: [email protected]; [email protected]
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 <[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 +
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Creating Certificates
2018-10-05 23:17 Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 09:46 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 14:47 ` Re: Creating Certificates Andrew Dunstan <[email protected]>
2018-10-16 02:45 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-16 02:49 ` Re: Creating Certificates Bruce Momjian <[email protected]>
@ 2018-10-16 12:02 ` Magnus Hagander <[email protected]>
2018-10-16 14:06 ` Re: Creating Certificates Bruce Momjian <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Magnus Hagander @ 2018-10-16 12:02 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Tatsuo Ishii <[email protected]>; Andrew Dunstan <[email protected]>; PostgreSQL-development <[email protected]>
On Tue, Oct 16, 2018 at 4:49 AM Bruce Momjian <[email protected]> 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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Creating Certificates
2018-10-05 23:17 Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 09:46 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 14:47 ` Re: Creating Certificates Andrew Dunstan <[email protected]>
2018-10-16 02:45 ` Re: Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-16 02:49 ` Re: Creating Certificates Bruce Momjian <[email protected]>
2018-10-16 12:02 ` Re: Creating Certificates Magnus Hagander <[email protected]>
@ 2018-10-16 14:06 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: Bruce Momjian @ 2018-10-16 14:06 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Tatsuo Ishii <[email protected]>; Andrew Dunstan <[email protected]>; PostgreSQL-development <[email protected]>
On Tue, Oct 16, 2018 at 02:02:48PM +0200, Magnus Hagander wrote:
>
>
> On Tue, Oct 16, 2018 at 4:49 AM Bruce Momjian <[email protected]> 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 <[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 +
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Creating Certificates
2018-10-05 23:17 Creating Certificates Tatsuo Ishii <[email protected]>
@ 2018-10-13 18:38 ` Bruce Momjian <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Bruce Momjian @ 2018-10-13 18:38 UTC (permalink / raw)
To: Tatsuo Ishii <[email protected]>; +Cc: pgsql-docs
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 <[email protected]>
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 protected]
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 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 +
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2018-10-16 14:06 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-10-05 23:17 Creating Certificates Tatsuo Ishii <[email protected]>
2018-10-06 09:46 ` Tatsuo Ishii <[email protected]>
2018-10-06 14:47 ` Andrew Dunstan <[email protected]>
2018-10-06 21:51 ` Tatsuo Ishii <[email protected]>
2018-10-16 02:45 ` Tatsuo Ishii <[email protected]>
2018-10-16 02:49 ` Bruce Momjian <[email protected]>
2018-10-16 12:02 ` Magnus Hagander <[email protected]>
2018-10-16 14:06 ` Bruce Momjian <[email protected]>
2018-10-13 18:38 ` Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox