On Mon, Aug 24, 2020 at 04:00:09PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@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 <br...@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index c8698898f3..a01add94b7 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -2193,8 +2193,10 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
The certificates of <quote>intermediate</quote> certificate authorities
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>
- extensions. This allows easier expiration of intermediate certificates.
+ intermediate certificates were created with <literal>v3_ca </literal>
+ extensions. (This sets the certificate's basic constraint of
+ <literal>CA</literal> to <literal>true</literal>.)
+ This allows easier expiration of intermediate certificates.
</para>
<para>
