Experimental TLSA support (merging the old tlsa branch into main dev)
#4087
Conversation
|
Anything we mere users can do to bump this one? It would be really nice to see. |
Hear, hear! 😁 Actually, when I submitted this PR in May, I was panicking because I had just turned on DANE on my mail server, misreading that Well, I didn't notice (at the time) that there are 167 pending PRs (as of the time of writing), as well as 740 pending issues, so the poor core developers have a lot to work with until they eventually stumble on this one... So now I have no choice but to use my own patched version, cross my fingers, and hope it works — or I can kiss bye-bye to all my emails (from two dozen domains!) 🤣 ... and a flurry of certificates have just been issued today, so the time is ticking for me... 🕐 |
|
Thanks for your PR. We have the same headache/usecase and I would love to check this out. Am I right in saying TLSA records have to be manually created first, then in future the DNS hook will update the records? |
|
Eeek. Lots of work for me again :-) @rjg7001 I'm not really sure, but I'd assume you're right. I'm afraid I haven't delved much deeper into the issue, and just noticed how far behind my own fork has strayed from the main branch :) I need to see if anything still works 🤣 |
|
Ok, I believe I've seriously messed up my fork, lol — so much, in fact, that now GitHub considers this branch to be "final", in the sense that it doesn't appear to be different from what GitHub already has on the main repository... I'm attempting to get thinks right again... |
|
Thank you so much, @Neilpang ! |
|
Actually... not fixed 🤣 This essentially just generates a new private key for the next round of key recycling. Close, but no cigar; what we need is a bit more than that, namely, generate the key pair and submit it via the DNS APIs as a TLSA record. Allegedly, my patch did that back then — before it became utterly out of sync with the main trunk — and it had some bugs as well. See the (continuing) discussion at #3096! I'd reopen this PR, but, unfortunately, I've deleted my own fork; I'd need to work on it again and see if I could manage to get it up to speed with the current version; but since it seems that there is some work in progress in this direction, done by someone who really knows what they're doing (unlike myself!). Also, it's wasteful to have two people working on the same issue, especially if one of them (yours truly) hardly knows what she's doing... |
This is my own attempt at trying to bring the TLSA branch into the main (dev) branch, by merging the old
tlsabranch (700+ commits behind at the last count) with the most recent version of the main branch.Essentially: this will enable
acme.shto deal with the complex issue of regenerating the TLSA hashes automagically when the LE certificate is renewed — a requirement for email servers that comply with DANE security measures.Because such hashes are stored on DNS, which can take a long time to propagate, it means that some email gets lost once a certificate is renewed (while DNS still propagates). DANE specifies that, in this situation, multiple hashes can be stored simultaneously on DNS, and email servers supporting DANE are required to test with all the DNS-stored hashes before (eventually) rejecting email; more specifically, in this scenario, it's best to keep the hash for the 'current' certificate as well as for the 'next' one (in the future): email servers will therefore have two choices, one of which should always work, independently on the speed of DNS propagation (which usually takes anything from a few picoseconds to several weeks — but rarely, if ever, months — depending on local configurations).
Fortunately, LE has no problem in issuing a 'future' certificate via their API. This gets retrieved and stored, then hashed and added on DNS. When the renewal date is due,
acme.shwill switch the current certificate with the 'future' one, and remove the 'old' hash from DNS (and let the change propagate...). Additionally, it will request a new certificate from LE with a date in the future, add that certificate's hash to DNS, and repeat ad infinitum et nauseam.See #3096 for a thorough discussion on the issues, and the work done so far on the
tlsabranch for further reference; note that some patches had been submitted via adiffpatch but not as a separate PR; this PR attempts to incorporate all these (proposed) changes.Closes #3096