Re: what can go in root.crt ? - Mailing list pgsql-hackers

On 06/12/20 15:13, Bruce Momjian wrote:
> On Wed, Jun  3, 2020 at 07:57:16PM -0400, Chapman Flack wrote:
>> here is a root.crt file for libpq containing only this exact cert, I
>> want libpq to connect only ever to this server with this cert and nothing
>> else. It's a pain because I have to roll out new root.crt files to everybody
>> whenever the cert changes, but it would be hard to call it unsafe.
> 
> I think you have hit on the reason CAs are used.  By putting a valid
> root certificate on the client, the server certificate can be changed
> without modifying the certificate on the client.
> 
> Without that ability, every client would need be changed as soon as the
> server certificate was changed.  Allowing intermediate certificates to
> function as root certificates would fix that problem.  When the
> non-trusted CA changes your certificate, you are going to have the same
> problem updating everything at once.

There seems to be a use of language here that works to make the picture
muddier rather than clearer.

I mean the use of "trusted"/"non-trusted" as if they somehow mapped onto
"self-signed"/"not self-signed" (unless you had some other mapping in mind
there).

That's downright ironic, as a certificate that is self-signed is one that
carries with it the absolute minimum grounds for trusting it: precisely
zero. There can't be any certificate you have less reason to trust than
a self-signed one.

(Ok, I take it back: a certificate you find on a revocation list /might/
be one you have less reason to trust.)

If a certificate, signed only by itself, ends up being relied on by
a TLS validator, that can only be because it is trusted for some other
reason. Typically that reason is that it has been placed in a file that
can only be edited by the admin who decides what certs to trust. By
editing it into that file, that responsible person has vouched for it,
and /that/ is why the TLS client should trust it. The fact that it is
self-signed, meaning only that nobody else ever vouched for it anywhere,
has nothing to do with why the TLS client should trust it.

Now, suppose that same responsible person edits that same file, but this
time places in it a cert that has been signed by some other authority.
That is a cert that has been vouched for in two ways: by the admin
placing it in this file, and by some other PKI authority.

As far as the TLS client is concerned, the endorsement that counts is
still the local one, that it has been placed in the local file by the
admin responsible for deciding what this client should trust. The fact
that somebody else vouched for it too is no reason for this client
to trust it, but is also no reason for this client not to trust it.
It is certainly in no way less to be trusted than a cert signed only
by itself.

The key point is that as soon as you find the cert you are looking at
in the local file curated by your admin, you know you've been cleared
to trust what you're looking at.

If the cert you're looking at is not in that file, and it has no signer
but itself, you must at that point fail. Dead end. There can be no reason
to trust it.

On the other hand, if you are looking a cert that has a signer, you have
not hit a dead end yet; you can climb that link and hope to find the signer
in your curated file, and so on.

You need to climb until you find something that's in that curated file.
Every step that you climbed needs to have had a valid signature made
while the signer was valid and not revoked, the signer needed to be allowed
to sign certs, and to sign certs for the subject's domain. Those things
needed to be checked at every step.

But once you have followed those steps and arrived at a cert that
was placed in your trust store by the admin, it's unnecessary and
limiting to insist arbitrarily on other properties of the cert you
found there.

> This is why a root certificate, which never changes, is helpful.

But who says it never changes?

As I mentioned earlier, my org has not always had its current procedures
on the issuance of certs, and not so many years ago did have its own
in-house CA. I ran across a copy of that CA cert recently. It was generated
in July of 2010 and is still good through next month. (I have not checked
to see whether the former in-house CA made a revocation entry somewhere
for it before turning the lights out.)

If we were still using that CA cert, I would still have to roll out
new root.crt files next month. I'm sure at the time it was generated,
ten years seemed like 'almost never', and like a reasonable time in which
to hope no adversary would crack a 2048 bit RSA key.

One certainly wouldn't plan on giving an important cert a lifetime
much longer than that.

So the benefit of putting a signing cert in root.crt is not so much
that it will never expire and need updating, but that you can keep
using it to sign other certs for new services you stand up or update,
and so you don't have to distribute new root.crt files every time you
do those things.

For that purpose, it matters not whether the signing cert you put there
is self-signed or not.

Regards,
-Chap