Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create (or output) DANE records #230

Open
ThomasWaldmann opened this Issue Feb 3, 2015 · 11 comments

Comments

Projects
None yet
9 participants
@ThomasWaldmann
Copy link
Contributor

ThomasWaldmann commented Feb 3, 2015

at 31c3, there was the suggestion to not only make getting and installing the certificate easy, but also optionally support creation of the DANE records in DNS (or at least output what should go there).

@jdkasten

This comment has been minimized.

Copy link
Contributor

jdkasten commented Feb 3, 2015

@schoen

This comment has been minimized.

Copy link
Contributor

schoen commented Feb 28, 2015

This seems to be straightfoward to do, but is also a pretty serious DoS possibility when combined with autorenewal (because the autorenewer doesn't have the ability to deploy new DANE records, the responsible party in the future might not know what DANE is even if the previous person who got the cert issued did, and the autorenewal might end up happening in a fully automated fashion without attracting human notice or intervention).

So I'm afraid that if we implement this feature, a lot of sites that use it feature will break upon renewal.

The renewal agent could probably detect whether there is a DANE record, and could also create new updated DANE records, but it doesn't clearly have a way of knowing whether there's a human being in the loop who will actually go out and deploy them!

@schoen

This comment has been minimized.

Copy link
Contributor

schoen commented Feb 28, 2015

We could make DANE and autorenewal from a cron job be mutually exclusive, so if you have a DANE deployment you have to run the renewal script interactively (and then be given new DANE records by the interactive renewal process).

@Lennie

This comment has been minimized.

Copy link

Lennie commented Mar 23, 2015

Here are some ideas:

Maybe just have an option to call a script or generic API/protocol (which people can write a proxy for to their own solution) ?

How about starting that process 2 weeks before renewal to make it less interactive:

  • generate the new key
  • generate a new DANE record
  • call a script or API so it can be added to DNS.

Then you you have 2 weeks to complain (automated email ?) that the DANE record isn't updated yet.

Or even better look at the DNS TTL to know how far in advance it needs to be updated.

An other option is:

DANE has the option to add the CA to DNS instead of the certificate:

http://tools.ietf.org/html/rfc6698#section-2.1.1

Maybe it would be a good idea to integrate well with that instead.

You can even just use the top root CA-certifcate, it doesn't have to be a sub-CA.

You could also start off with on the first deployment: just having the code to check DNS to see if it's DNSSEC signed and if DANE is used. Then fail to do the next steps before the operator has updated the DNS-record.

@kroeckx

This comment has been minimized.

Copy link

kroeckx commented Nov 4, 2015

If the private/public key is reused you can set up DANE with that key and you wouldn't need to roll over the records. You currently don't seem to be able to reuse the key.

@cfaerber

This comment has been minimized.

Copy link

cfaerber commented Oct 28, 2017

Certbot now has plugins to automatically install DNS records for challenges. Updated TLSA records could be installed in the same way.

Support for generating TLSA records would also require a two-phase install process: (1) get a new certificate and generate new (candidate) TLSA records, (2) after the TLSA records have been up for at least 2 to 3 times their TTL, install the new certificate.

@kroeckx

This comment has been minimized.

Copy link

kroeckx commented Jul 28, 2018

This is still the reason I'm not using a letsencrypt certificate for SMTP. Either I disable DANE or use a self-signed certificate.

@sydneyli sydneyli added this to the Wishlist milestone Sep 13, 2018

@Snawoot

This comment has been minimized.

Copy link

Snawoot commented Nov 2, 2018

@kroeckx @cfaerber

Support for generating TLSA records would also require a two-phase install process: (1) get a new certificate and generate new (candidate) TLSA records, (2) after the TLSA records have been up for at least 2 to 3 times their TTL, install the new certificate.

This is still the reason I'm not using a letsencrypt certificate for SMTP. Either I disable DANE or use a self-signed certificate.

Why such complications? I use Letsencrypt and DANE for SMTP. certbot has option to retain old secret key like this:

[renewalparams]
reuse_key = True

All you have to do is to pin only key part in DANE (not entire X509 cert). Renewed certs will have same pubkey and will match DANE record too.

Disclaimer: I see no point in frequent key regeneration and short living certs. I don't see why pubkey signed 5 minutes ago (probably because of IP address hijack via BGP) is more trustworthy than pubkey established and known for long term.

@kroeckx

This comment has been minimized.

Copy link

kroeckx commented Nov 2, 2018

@sydneyli

This comment has been minimized.

Copy link
Member

sydneyli commented Nov 2, 2018

It's a lot easier to do DANE now that --reuse-key has landed! Thanks @schoen :)

But, if you still want to occasionally regenerate your keys, maybe once a year or so, you have to go in manually and roll over your Certbot key by running it once without --reuse-key set, then set it again.

Right now, it's best to publish TA records with Let's Encrypt's current cert (& backup cert) as backups and manually do the EE record rollover occasionally. I'm working on a blog post to make this process clearer!

In the meantime, some avenues of exploration for even better DANE support:

  • integration with DNS plugins (mentioned above)
  • tune-able key rollover frequency
  • make it possible to only publish EE records (and not have to trust upstream at all) with Certbot keys by pre-generating the next key/CSR
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.