SSL Let's Encrypt expired after 90 days

[mattia]

I saw that this morning I had a problem with the certificate, it was expired, so I run again “ansible-playbook server.yml -e env=production --tags letsencrypt” and it is all ok now.

I would like to know how works the automatic renewal cron-job, the documentation says:

There is one main difference between LE and other certificate authorities: their certificates expire every 90 days . Trellis automates by running a cron-job so you never have to manually renew them or worry about them expiring like a paid certificate.

I had the feeling that this cron-job was already automatically configured in Trellis, but now I am wondering if I need to set up the cron-job somewhere in the settings?

I am on DO droplet and my trellis version is not very old (july 2018), do you have any idea why the cron-job have failed?
What I can do to check if the cron-job is correctly in place?
is there any test that I can run just to be sure that the cron-job will work the next time (90 days from today)?

thanks in advance for your help.

[jonathanlaf]

You can log in via SSH and type:

sudo crontab -l

You should see all crontab

• You can also read this documentation online if you ever need to set it manualy : How to Display (List) All Jobs in Cron / Crontab

In another hand, I havent checked it, but they should use certbot for the certificate, so you can just try this:

sudo certbot renew --dry-run

Source: https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-18-04

[mattia]

I tried “sudo crontab -l” and I received this output

no crontab for xxxxx

Then, I tried “sudo certbot renew --dry-run”

certbot: command not found

what else I can try?
Am I missing something in the trellis’s configuration?

Thanks

[jonathanlaf]

Humm, I don’t know how Trellis Manage them SSL Certs, but I would recommand you to manually install certbot, it’s really easy to use.

[swalkinshaw]

@mattia

I had the feeling that this cron-job was already automatically configured in Trellis, but now I am wondering if I need to set up the cron-job somewhere in the settings?

Trellis does configure this automatically. See here for the task which does this: https://github.com/roots/trellis/blob/82a67200fe1225f8247a5368918db0b7f9f71842/roles/letsencrypt/tasks/main.yml#L6-L15

You can verify this exists by opening /etc/cron.d/letsencrypt-certificate-renewal as the root user.

It simply runs this command though:

cd /var/lib/letsencrypt && ./renew-certs.py && /usr/sbin/service nginx reload

You can manually run that and see what the output is (but it will skip if the cert is <60 days old).

I’d suggest checking logs to see if there were any cron errors which I think would be in /var/log/syslog.

[mattia]

thanks @swalkinshaw for your reply.

I can see the letsencrypt-certificate-renewal file and his content

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

I tried to run cd /var/lib/letsencrypt && ./renew-certs.py && /usr/sbin/service nginx reload
but i received this error -bash: cd: /var/lib/letsencrypt: Permission denied

I tried with the admin user and with the web user, but with the same result.

I checked the /var/log/syslog with this command (sudo grep cron /var/log/syslog), this is what I can see:

Aug 20 15:15:01 xxxxx-production CRON[7020]: (web) CMD (cd /srv/www/xxxxx.co.uk/current && wp cron event run --due-now > /dev/null 2>&1)
Aug 20 15:17:01 xxxxx-production cron[1403]: Authentication token is no longer valid; new one required

another test that I did, it was to check (via SFTP) the Chmod permissions of the /var/lib/letsencrypt folder.
the Chmod permission is 700, owner and group are root.
is this right?

what else I can try to do? any other ideas?
thanks

[swalkinshaw]

I googled that error and it appears to mean a user password was changed/expired on the server. Ref: https://deveshdba.wordpress.com/2016/10/03/authentication-token-is-no-longer-valid-new-one-required-crontab-issue/

[mattia]

@swalkinshaw thanks, i checked the password of the root user and my admin_user (that it is not admin, but a different name, I changed it when I did the first set up)

I run sudo chage -l root and this is the result, it seems that I need to change the password.

and the I run sudo chage -l my-admin-username-xxx and the result is:

is the ssl cron-job run by the root user or the admin_user?

so I reckon the next steps are changing the root password and re-provisioning the live server, is that correct?
is there something else that I should do after these steps?

thanks!

[swalkinshaw]

@mattia

is the ssl cron-job run by the root user or the admin_user?

so I reckon the next steps are changing the root password and re-provisioning the live server, is that correct?

Yes to both I’m pretty sure. That should be it but I don’t know off the top of my head

[mattia]

@swalkinshaw do you know if i can change the root password directly in the digital ocean control panel (see attachment) or i need to do this via the console with “sudo passwd root” or i can try with the digital ocean web-based console (/products/droplets/resources/recovery-console/)?

Could you please let me know what it will be your preferred option between these 3?
I am not confident with the console commands, and I don’t mess up with the production server.

thanks in advance.

[ngerakines]

It also might be a good idea to consider some sort of ssl monitoring like www.sslhound.com or something.

[swalkinshaw]

I’d probably use that DO console button?