Moving from LetsEncrypt renewal to Certbot

[burnsj77]

Hi, I deployed my first every https site last year on Digital Ocean using letsencypt. I was delighted to finally get a green ‘tick’ for a secure site and have diligently run the renew script every 3 months.

I have just configured my second server and, using updated instructions, got https working using certbot, which indicates it will auto-renew. Nice!

My question is, back on my first server, how do I migrate from using the ‘sudo letsencrypt renew --agree-tos’ command to asking certbot to automatically upgrade. Can I do a fresh Certbot deployment so it ‘takes over’ before my cert is expired? Do I need to wait until expiry? Or is there a migration approach I should consider while my cert is still valid?

Thanks in advance for any advice…

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: https://wealth-hack.com

I (normally) run this command: sudo letsencrypt renew --agree-tos

It produced this output:. It works, but manually requires me to do this every 3 months. I would like to automate using Certbot.

My web server is (include version): Apache/2.4.18 (Ubuntu)

The operating system my web server runs on is (include version): Ubuntu 16.04

My hosting provider, if applicable, is: Digital Ocean

I can login to a root shell on my machine (yes or no, or I don’t know): Yes.

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No, command line only.

[_az]

It should automatically renew on your first server, too. letsencrypt is the same software as certbot, the name just differs between distributions and operating systems.

Could you run, on your first server:

letsencrypt --version
ls -la /etc/cron.d/{letsencrypt,certbot}

[burnsj77]

Wow _az, what a rapid response. Many thanks:)

letsencrypt version is:

letsencrypt 0.4.1

when I try and run this command on my original server:

ls -la /etc/cron.d/{letsencrypt,certbot}

it gives me the following cannot access message:

ls: cannot access '/etc/cron.d/letsencrypt': No such file or directory
ls: cannot access '/etc/cron.d/certbot': No such file or directory

I don't believe I have certbot installed. But letsencrypt is.......

[_az]

That’s a very old version of letsencrypt/certbot. You should replace it with an up-to-date one.

You can do this by visiting https://certbot.eff.org/lets-encrypt/ubuntuxenial-apache and following the instructions.

It should automatically pick up your existing certificate renewal configuration. After installing certbot this way, you shouldn’t need to do anything, but you can test it out using:

certbot certificates
certbot renew --dry-run

This method of installation will also install a scheduled task to your server, so you don’t need to worry about running it every 3 months.

[mnordhoff]

For that matter, the up-to-date Certbot package includes both “certbot” and “letsencrypt” executables for backwards compatibility, so you can continue using the same “letsencrypt” commands as before.

As _az said, the Certbot package automatically configures automatic renewal, so you don’t have to do that by hand anymore.

[burnsj77]

This is such a great community, many thanks for your support all. I updated all the latest packages as per this, ran certbot, it picked up my settings from letsencypt and processed first time:)

I also ran the following to trigger auto-renew:

sudo certbot renew

which 'failed' as there is now 3 months until re-cert time. What I'm not entirely sure is if it will auto-retry from this point onwards??

[mnordhoff]

A timer should have been set up when the Certbot packages were installed. You can use "systemctl list-timers" to confirm it's running, or check /var/log/letsencrypt/letsencrypt.log around 00:00-01:00 and 12:00-13:00 in the server's time zone.

@burnsj77

which ‘failed’ as there is now 3 months until re-cert time.

If it said all of your certificates are not due for renewal yet, that's good.

You can use "sudo certbot renew --dry-run" to help test it: it uses the staging environment to issue fake certificates (and then discards them without touching your real certificates).

[burnsj77]

Such useful advice, ‘systemctl list-timers’ confirms I am good to go.

Couple of small threads that are not game changing but while I have expert eyeballs in this space, I thought I would check in on. As much as anything, the advice gained (and shared) will hopefully help others with a lower skill base such as my own!

1.When I check the log files re. the auto-cert job, it looks like it is trying to process two certs. The one I created last night (which looks to be tested successful) and a second cert which seems to be a vestige of my old letsencrypt upgrade process. Essentially, the job is trying to process two separate conf. files. I don’t think the second one will break the first when this runs proper in 2 months time, but would it be wise to delete the ‘broken’ .conf to remove it from the auto-renew? Or is their a cleaner way to force the job to only work with 1 conf file.

2. My old certifications process had 6 domains all wrapped into one cert request. Subsequently, I have (purposely) let 3 of those domains lapse. The new functioning certification has 2 of my remaining domains, but missed the third. How do I go about adding it?

Apols for diving down the rabbit-hole Team LetsEncrypt. Hoping with your guidance to have this renewal process clean as a whistle going forward:)

Cheers
James.

[schoen]

@burnsj77

1.When I check the log files re. the auto-cert job, it looks like it is trying to process two certs. The one I created last night (which looks to be tested successful) and a second cert which seems to be a vestige of my old letsencrypt upgrade process. Essentially, the job is trying to process two separate conf. files. I don’t think the second one will break the first when this runs proper in 2 months time, but would it be wise to delete the ‘broken’ .conf to remove it from the auto-renew? Or is their a cleaner way to force the job to only work with 1 conf file.

You can use certbot delete to delete it (first making sure that you don't have any server configurations that are still pointed at it).

@burnsj77

My old certifications process had 6 domains all wrapped into one cert request. Subsequently, I have (purposely) let 3 of those domains lapse. The new functioning certification has 2 of my remaining domains, but missed the third. How do I go about adding it?

You can use certbot certonly --cert-name the-cert-name -d onedomain.example.org -d anotherdomain.example.org -d thirddomain.example.org to reissue the certificate to cover all three names.

[burnsj77]

Outstanding advice @schoen. In terms of my two outstanding threads:

1. I used certbot certificates to re-assure myself, there was two certs left (and to confirm which one needed deleting). certbot delete was reassuring newbie proof and I followed up with a certbot --dry-run to confirm a positive outcome.

2. Again, the advice on certbot certonly to re-issue with an additional domain included worked a charm. It did take me a few goes to get right the command arguments right so for future newbies, my actual command (stripped of my actual URL's) may help:

sudo certbot certonly --cert-name mycertname -d url1.com -d www.url1.com -d url2.com -d www.url2.com

I used SSLLabs tester to validate the outcome was good (it was) and a final certbot --dry-run as a final final double check of success! I now have what appears to be an automated set of SSL certs, all running via CertBot!

Again thank to @schoen, @mnordhoff and @_az for your support. Hope this thread helps someone else out next time.......

Cheers
James.