Autorenew certificates every 60 days

[joallard]

As stated by Letsencrypt, they want clients to renew certs automatically, hence the purposefully inconvenient 3 month duration. Here's how to go about this gradually:

• [ ] Make the script directly put the keys in place, whether in a folder or Heroku given proper rights
• [ ] Make a process for the plugin to get keys and access the Heroku API to change keys
• [ ] Figure out a cron job or something to do this automatically every 2 months

I'll try to tackle this according to my schedule.

[enhancement]

[toobulkeh]

I would love to see this and help. I think a limitation is the heroku permissions. Apps don't have the ability to auto-configure themselves. Therefore it probably needs to be a heroku element.

[joallard]

I think there's a way to do it with the Heroku API and some keys. I don't recall if that gives the app permission over all your apps or just granularly. We could probably even reach out to them about that.

[toobulkeh]

I think what you're referring to is the "Platform API".

Their authentication methods are per-user, which is as good as account-wide access. To use that method, you'd need a specific user created just for that app, which they don't have in a published format (and it's a 2-step web process which parses a URL from an email address). So I think the correct way to handle this is a separate web app that can be run as a "heroku element". I wonder if we could use the running web-app as a self-registering Heroku Element (doesn't even need to go through the publishing process), because if we were to create another service that would end up signing certificates, then that's just another link in the chain of security that could be broken. I think it'd be fine if Heroku were to maintain it (I don't see LetsEncrypt taking on that responsibility), but I personally wouldn't want to be responsible for that at scale (or form a Company that would).

As far as automating this on a recurring basis, Something would have to trigger the refresh every 60 days (leaving a month of troubleshooting before expiration occurs). You could put it into a rake task in the app itself, but that would need to be kicked off by the heroku-scheduler cronjob. (it would be nice if LetsEncrypt supported a callback URL config instead of just hard-to-parse/automate emails!)

The Heroku Scheduler has a limitation of being daily as the maximum cron setting. This would mean the script would have to analyze the cert itself to see if it was within a threshold of being reset OR we could setup a DB variable on the setup action and keep it updated.

[joallard]

Great analysis @toobulkeh! Indeed, looks like it'd make sense for everyone to bring them in to that discussion. I'm going out on a limb here, but maybe we could ping @schneems if he'd be so nice as to give us his insight?—If not I can probably ping their support to bring their attention to this issue.—Is that in Heroku's plans? I think it'd be in the interest of both the community and Heroku to advance this feature.

[schneems]

I use https://github.com/dmathieu/sabayon for CodeTriage.com to auto renew certs

[toobulkeh]

A quick analysis of Sabayon -- it's a separate Go application that runs on heroku scheduler daily to renew a single certificate of another application -- using a Heroku API key (per user) and static configuration variables.

It also requires a manual setup process inside the Rails (or other) application for LetsEncrypt (instructions for rails included).

I think it would be useful to extract this functionality to a rake task on the Rails app itself to minimize footprint just for this one feature and to streamline deployments.

This still has the problem of requiring a Heroku API key / user account with just production access -- but I don't forsee any way of getting around that, unless Heroku changes their permissions to allow for an app to access its own Heroku config (sounds like a big security concern to me). Though an ENV variable with a Heroku API key is just about the same risk.

[schneems]

I like having the token in a separate app. If you've got an RCE and the token is in the same app someone could take over your app with their own malicious code then use the API token to provision more resources. If there are separate you would still get pwned but at least they can't mess with resource provisioning or config vars etc.

I wish we could scope a token better but it's all we've got for now.

[tf]

We've created https://github.com/codevise/cert_watch to manage and renew certificate via Resque jobs. It's only a couple of days old.

It's a Rails engine that comes with an optional Active Admin integration. It currently works only with the certbot executable, but supports an adapter mechanism that should make it easy to integrate with tools like acme-client or this gem.

[toobulkeh]

So based on a month working with this stuff -- we really like the sabayon side-app with permissions mentioned above.

I would recommend changing this plugin / engine to use the same ENV VAR technique that app suggests -- so that it can be completely automated.

The only problem we haven't worked through is that we're using config.force_ssl in most of our apps. I would suggest trying to add a skip_before_action :force_ssl to this Rails Engine to see if that forces the engine's routes to always use HTTP instead of HTTPS.

We've ran into a few problems with some packages not supporting SSL+SNI which the new Heroku endpoints require -- but we've managed to work around those.

Hope this helps!

[jasper-lyons]

#45 + #47 lets you use heroku env vars to manage anything in the config.

[c-lliope]

Just want to mention – I switched to https://github.com/elct9620/rails-letsencrypt/ to manage this for my non-Heroku app. It supports autorenewing (you need to set up a cron job), and the API seems a bit more straightforward to me.