A sensible "3 1 1" + "3 1 1" key rotation approach
ietf-dane at dukhovni.org
Fri Feb 16 21:05:20 CET 2018
To avoid (even temporary) mismatches always publish multiple (two
are enough) TLSA records. One for matching the current certificate
chain, and another matching the *future* certificate chain.
You might ask how the *future* certificate chain can be predicted,
but the answer is simple enough. While you may not know all the
certificate details, you can control the public key that goes into
the future certificate. This can be matched with a "3 1 1" record.
Therefore, the recommended key rotation approach is:
1. Whenever you *deploy* a certificate chain with a new key,
at the same time (that way you won't forget later) generate
the next key! And that time update your TLSA records to match
both keys. You only need the next public key for this, the
next private key could be password protected if you like, but
for most sites just rotating the keys often and letting the OS
protect the keys from all but the authorized account is enough.
_25._tcp.smtp.example.com. IN TLSA 3 1 1 <sha256(curr key)>
_25._tcp.smtp.example.com. IN TLSA 3 1 1 <sha256(next key)>
2. When it is time to obtain a new certificate, generate the CSR
from the previously generated *next* key (this may require
decryption of the private if stored encrypted initially) and
request the certificate, *but* do that only if the corresponding
TLSA record is already published! Do the DNS lookup to verify.
3. To deploy the newly obtained certificate go back to step 1.
More information about the dane-users