Add TLSA support
BartG95 opened this issue · comments
Feature request: update the tlsa record of each domain after successful renewal. This can be done with a deploy-hook.
Of course, the script should wait till the tlsa record is in place, and only then delete the old tlsa record and run other deploy-hooks.
More info:
[1]: https://www.transip.nl/knowledgebase/artikel/857-een-tlsa-record-instellen/
[2]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#TLSA_RR
I'm not very familiar with the TLSA record. Webbrowser implementation seems lacking. What are good reasons to create this record? You have to help me out a little. How would you want to see this implemented? I can imagine a config option to toggle the creation / update of the TLSA record(s). Do you have a suggestion for default values for the certificate usage,
selector and matching type? Should they be configurable or can these be fixed?
I am not sure if there are good reasons, for now. Support for it is indeed mostly lacking.
But I like the idea of verifying certificates via DNS, because it would make us less dependent on CA's.
As for the configuration: I suggest to create a third script, besides the pre and the post hook script. Users who want TLSA can then optionally run this third script as a deploy hook of certbot.
I suggest to add an option in the config file with an array of TLSA records a user wants by default. I think it will be a little difficult to configure this per domain, but I also think it is not very necessary to have this per domain.
Anyway, I don't think it is important. More something for the long term.
I do not intend to make the PR myself, for now.
I'm not very familiar with the TLSA record. Webbrowser implementation seems lacking. What are good reasons to create this record? You have to help me out a little. How would you want to see this implemented? I can imagine a config option to toggle the creation / update of the TLSA record(s). Do you have a suggestion for default values for the certificate usage,
selector and matching type? Should they be configurable or can these be fixed?
A TLSA record is requited to setup an SMTP server with STARTTLS and DANE support.
See: https://www.forumstandaardisatie.nl/open-standaarden/starttls-en-dane
I just took another look at it. It would be nice if it could be implemented. For the config file, would a list of configurations for the TLSA records be sufficient? Do I understand it correctly that, first the new domain certificate must be generated and then I can use the contents of cert.pem to generate the TLSA record? Shouldn't be too hard I think.
[
...,
'tlsa' => [
[
'port' => 443,
'protocol' => 'tcp',
'domain' => 'sub.example.org',
'usage' => 1,
'selector' => 2,
'matching-type' => 3,
],
[
...
],
]
];It depends on the type of tlsa record you choose. For type 3 1 1 the tlsa record stays the same if the private key for signing is reused. For type 3 0 1 the whole cert is used.
This probably needs support in certbot itself as well, because the 'live' keys must only get updated after the TLSA records are updated.
Relevant issues in certbot:
This probably needs support in certbot itself as well, because the 'live' keys must only get updated after the TLSA records are updated.
The new keys must be published before deployment, then there should be some time to allow DNS to propagate the keys first. The old key can be removed when the new cert is deployed.
I just took another look at it. It would be nice if it could be implemented. For the config file, would a list of configurations for the TLSA records be sufficient? Do I understand it correctly that, first the new domain certificate must be generated and then I can use the contents of cert.pem to generate the TLSA record? Shouldn't be too hard I think.
[ ..., 'tlsa' => [ [ 'port' => 443, 'protocol' => 'tcp', 'domain' => 'sub.example.org', 'usage' => 1, 'selector' => 2, 'matching-type' => 3, ], [ ... ], ] ];
There is no need to add much configuration, I think. The TLSA record can be pushed to _dane.example.com. Then stuff like _433._tcp.example.com can be manually added as CNAME to _dane.example.com. (This is for example what soverin.net does.)
It prevents pushing and updating an identical TLSA record for every port/protocol combination. Also, enabling it for another port/protocol is most likely a manual action anyway.
A few thoughts:
- In dunne cases, where the private key is not changing the TLSA record does not change either (3 0 1) and (2 0 1).
- In all other cases the old record should not be deleted immediately, but not before a retention time of let's dat 72h.
- Also a new TLSA record needs to be published 24h in advance to let DNS propagation take place, because we do not want a low TTL here.
I wrote a script that implements this idea. See https://codeberg.org/bartavi/asselt.