A sensible "3 1 1" + "3 1 1" key rotation approach
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
participants (1)
-
Viktor Dukhovni