mcr at sandelman.ca
Wed Sep 2 03:09:18 UTC 2020
Having read through the thread, I think that Viktor is assuming that the
private key will always be replaced.
My reading of the CABForum push towards 13 month validity, and the
LetsEncrypt 90-day process it that private key replacements are not
necessarily replaced that often.
The shortest *certificate* lifetimes are driven by a desire to eliminate some
CRL/OCSP stuff a la
RFC 8739 (was draft-ietf-acme-star)
Support for Short-Term, Automatically Renewed (STAR) Certificates in the
Automated Certificate Management Environment (ACME)
Watching the certificate file and reloading it would suffice for 90% of uses.
Viktor suggests using the combined private-key/certificate format.
I think that's a undesired constrait.
For the paranoid who want to encrypt their private keys and type passphrases
when whey reload would probably not like that.
It probably also fails if the private key is in an HSM (and you don't replace
that private key as often, I imagine).
In all algorithms I'm aware of, the public key can be derived from the private key,
so we can check if the loaded private key matches the public key in the
certificate. (I seem to remember some attack on some systems where doing that
checked defeated the attack, but I can't recall which one)
So it seems that we can easily use the mis-match of the keys to trigger a
check on the private key file, and if we can't load it (passphrase, etc),
then we could actually reject reloading the certificate file.
The operator has clearly done something wrong, or the file system hasn't
caught up to a consistent state... and the operator should do a manual
Oh, and while I think that openssl should have some reference code that uses
openat(), I rather suggest that this is reference code. Let the application
deal with setting up and processing the file update events, and calling
OpenSSL to potentially load a new certificate/key pair.
OpenSSL should focus on the reference counting needed underneath.
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the openssl-users