mbays at sdf.org
mbays at sdf.org
Fri Mar 5 18:14:39 GMT 2021
* Friday, 2021-03-05 at 13:33 +0100 - nothien at uber.space <nothien at uber.space>:
>I think that people find TOFU controversial because it [...] prevents
>servers from ever being able to change certificates.
Yes, this is a real problem. Even with a long-lived certificate you will
need to change it eventually to keep up with developments in
But I think we can solve this neatly by using certificate chains. If you
have a certificate which is trusted by many users and want to rotate to
a new certificate, sign the new certificate with the old one (treating
it as a CA) and have your server present the old certificate and the new
one as a chain. Then users will be able to see that they should carry
over their trust in the old certificate to the new one.
Clients should either warn the user about the change while providing
enough information that the user can see what has happened, or could
optionally automatically transfer trust to a cert signed by a previously
trusted cert for the same domain (being careful about wildcards!).
Some clients already provide enough information, i.e. fingerprints for
the old trusted cert and all certs in the new chain. But I see that not
I tested the signing process, and it seems straightforward. Here's what
I did, but please don't slavishly copy this; this is the result of a few
minutes with man openssl-x509, and I may be missing some important steps
(e.g. I ignored serial numbers, which I *think* makes sense, but maybe
I'm missing something):
gemcert -server mydomain
openssl x509 -CA old.crt -CAkey old.key -in mydomain.crt -out signed.crt
cat signed.crt old.crt > chain.crt
Now give chain.crt and mydomain.key to your server.
Here old.crt was also generated by gemcert.
Am I missing something, or does this make sense?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: not available
More information about the Gemini