Thread: Openssl v3_ca
A few years ago I figured out how to create intermediate certificates
that are transferred across OpenSSL connections by using the v3_ca
extension, and added this to the PG documentation.
I have now just figured out that v3_ca is just a heading in the openssl
configuration file, e.g., /etc/ssl/openssl.cnf, and that it is
specifically this line that enables this to work:
basicConstraints = critical,CA:true
I have created the attached documentation patch to clarify exactly what
is needed, in case non-openssl tools are used.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Attachment
Greetings, * Bruce Momjian (bruce@momjian.us) wrote: > A few years ago I figured out how to create intermediate certificates > that are transferred across OpenSSL connections by using the v3_ca > extension, and added this to the PG documentation. > > I have now just figured out that v3_ca is just a heading in the openssl > configuration file, e.g., /etc/ssl/openssl.cnf, and that it is > specifically this line that enables this to work: > > basicConstraints = critical,CA:true Yes, v3_ca refers to a stanza in the default openssl config. > I have created the attached documentation patch to clarify exactly what > is needed, in case non-openssl tools are used. > diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml > index c8698898f3..f705c4fec1 100644 > --- a/doc/src/sgml/runtime.sgml > +++ b/doc/src/sgml/runtime.sgml > @@ -2194,7 +2194,8 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433 > can also be appended to the file. Doing this avoids the necessity of > storing intermediate certificates on clients, assuming the root and > intermediate certificates were created with <literal>v3_ca</literal> All CAs need to have CA:TRUE set on them, root and intermediate, so the above isn't really correct.. > - extensions. This allows easier expiration of intermediate certificates. > + extensions (which sets <literal>CA:TRUE</literal> on certificates). Probably better would be to specifically say "This sets 'ca' to 'true' for the basic constraints of the certificate." or similar language. Simply saying "CA:TRUE" doesn't seem to really be an improvement over just referencing the v3_ca stanza. > + This allows easier expiration of intermediate certificates. While true, there's certainly other reasons why someone might want to run intermediate CAs.. I'm not sure that we really need to go into the discussion about why they make sense to have. Thanks, Stephen
Attachment
On Mon, Aug 24, 2020 at 04:00:09PM -0400, Stephen Frost wrote: > Greetings, > > * Bruce Momjian (bruce@momjian.us) wrote: > > A few years ago I figured out how to create intermediate certificates > > that are transferred across OpenSSL connections by using the v3_ca > > extension, and added this to the PG documentation. > > > > I have now just figured out that v3_ca is just a heading in the openssl > > configuration file, e.g., /etc/ssl/openssl.cnf, and that it is > > specifically this line that enables this to work: > > > > basicConstraints = critical,CA:true > > Yes, v3_ca refers to a stanza in the default openssl config. > > > I have created the attached documentation patch to clarify exactly what > > is needed, in case non-openssl tools are used. > > > diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml > > index c8698898f3..f705c4fec1 100644 > > --- a/doc/src/sgml/runtime.sgml > > +++ b/doc/src/sgml/runtime.sgml > > @@ -2194,7 +2194,8 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433 > > can also be appended to the file. Doing this avoids the necessity of > > storing intermediate certificates on clients, assuming the root and > > intermediate certificates were created with <literal>v3_ca</literal> > > All CAs need to have CA:TRUE set on them, root and intermediate, so the > above isn't really correct.. Uh, I think you can get away, at least in Postgres, of not setting CA:true for root certificates. In fact, you can even skip it for intermediates if you make sure the intermediate cert is on both sides of the SSL connection. I found this v3_ca because some people were saying you had to have the intermediates on both sides, and others said it would be shipped, and I was unclear why it only worked some of the time. v3_ca was the answer to having them shipped. > > - extensions. This allows easier expiration of intermediate certificates. > > + extensions (which sets <literal>CA:TRUE</literal> on certificates). > > Probably better would be to specifically say "This sets 'ca' to 'true' > for the basic constraints of the certificate." or similar language. > Simply saying "CA:TRUE" doesn't seem to really be an improvement over > just referencing the v3_ca stanza. Good, I was unclear what wording to use; updated patch attached. > > + This allows easier expiration of intermediate certificates. > > While true, there's certainly other reasons why someone might want to > run intermediate CAs.. I'm not sure that we really need to go into the > discussion about why they make sense to have. Agreed. If we wanted to get into that, we would need to make a new doc section about it. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Attachment
On Mon, Aug 24, 2020 at 04:52:24PM -0400, Bruce Momjian wrote: > > While true, there's certainly other reasons why someone might want to > > run intermediate CAs.. I'm not sure that we really need to go into the > > discussion about why they make sense to have. > > Agreed. If we wanted to get into that, we would need to make a new doc > section about it. Applied. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee