Certbot instead acme-tiny?

trellis
1

Why is acme-tiny used by trellis instead the official certboot tool?
certbot also supports webroot mode for being used with nginx.

2

I don’t think certbot existed when we first implemented this feature.

Ansible also has an official module we could use. I’d be open to anything that simplifies the LE feature though.

3

There is also a certbot plugin for nginx (https://certbot.eff.org/docs/using.html#nginx), but like the ansible letsencrypt module, both are still in alpha/preview.
The certbot nginx plugin would be a “perfect” solution - but it doesn’t seem to be production-ready yet.

4

Hopefully it’s time to revisit this by now.

I just had a site go down because acme-tiny failed on me. It seems the agreement PDF URL had changed and so the renewal script was failing, but the error output of this cron job wasn’t being sent to me.

I also then didn’t get emailed by Let’s Encrypt to tell me the certificate was going to expire, because acme-tiny doesn’t support sending contact details at registration time (and the author doesn’t want to add this feature).

1 Like
5

Some details I just sent to a dev group I’m part of, which I think may help others, so I’ll reproduce it here:

I just had a Trellis site go down because its Let’s Encrypt cert didn’t renew. Angry customer. It turns out the LE client they use (GitHub - diafygi/acme-tiny: A tiny script to issue and renew TLS certs from Let's Encrypt) fails if the LE licence agreement PDF URL changes, which it did, and the cron job Trellis sets up for LE doesn’t actually email you any error output, so I had no idea. On top of that, acme-tiny doesn’t support sending an email address along with a cert issue request, so LE itself doesn’t email me if the cert is nearing expiration.

Steps I took:

  1. Patch acme-tiny (see my branch at https://github.com/tremby/acme-tiny/tree/add-contact-option which is based on someone else’s PR https://github.com/diafygi/acme-tiny/pull/153 which rightly hasn’t been accepted yet because it has a syntax error) to allow an email address to be set

  2. Configure the letsencrypt ansible role to use this version, which involves setting acme_tiny_repo and acme_tiny_commit to point to my commit in roles/letsencrypt/defaults/main.yml

  3. Configure it to send to my email address, which means adding a letsencrypt_contact key with my email address to the same file roles/letsencrypt/defaults/main.yml, and then patching roles/letsencrypt/templates/renew-certs.py to add --contact {{ letsencrypt_contact }} to the list of options passed to acme-tiny

  4. Patch roles/letsencrypt/tasks/main.yml to add a new task to add the mail destination to the cron job. That looks like a new task in there like this:

    - name: Add email destination to key generation cronjob
  cronvar:
    name: MAILTO
    value: me@example.com
    cron_file: letsencrypt-certificate-renewal

  5. Delete current certs and rerun the letsencrypt role by following instructions here https://discourse.roots.io/t/update-lets-encrypt-certificates/7982/2

2 Likes
6

Thanks for all the details.

I’m a little confused about the PDF agreement URL. It seems like it last changed in August 2016. Is that still the case?

Beyond setting an email, it seems like there’s another proper fix too: https://github.com/diafygi/acme-tiny/issues/135

1 Like
7

So I had a similar certificate expire issue and I found out that in the cronfile for calling the renewal script, the days field value is still uninterpolated ansible variable!

#Ansible: letsencrypt certificate renewal
30 4 1,11,21 * * root cd /var/lib/letsencrypt && ./renew-certs.py && /usr/sbin/service nginx reload
    day: "{{ letsencrypt_cronjob_daysofmonth }}"
8

what O_O

What’s weird is the day is correctly added

letsencrypt_cronjob_daysofmonth: 1,11,21

Check the contents again:

30 4 1,11,21 * * root cd /var/lib/letsencrypt && ./renew-certs.py && /usr/sbin/service nginx reload
    day: "{{ letsencrypt_cronjob_daysofmonth }}"

and 1,11,21 appears correct.

Might be an Ansible bug that is then appending the day to the end of job?

2 Likes
9

How can I test this cronjob (script) directly and find out whether this extra line prevents proper execution?

10

Not really sure. Maybe run-parts /etc/cron.daily

Ref: https://unix.stackexchange.com/questions/42715/how-can-i-make-cron-run-a-job-right-now-for-testing-debugging-without-changing

I’m surprised that’s even a valid cron file. Maybe if you run crontab path/to/crontab/file it might show errors.

1 Like
11

I’m a little confused about the PDF agreement URL. It seems like it last changed in August 2016. Is that still the case?

The error I was getting when I tried to manually run the cron script was definitely to do with that. I think it’s possible that before this expiry I had simply reprovisioned the servers at least once every three months and so by coincidence I never saw a certificate expire.

Beyond setting an email, it seems like there’s another proper fix too

A proper fix to that issue, which has not yet been merged, but in my opinion getting the warning email from Let’s Encrypt is absolutely vital.

12

I agree :slight_smile: Using another method would probably be better. Ansible even has an official module now: http://docs.ansible.com/ansible/latest/letsencrypt_module.html

However, this isn’t on our current list of priorities.

1 Like