How to update browser with new SSL certificate?

Help
1

My certificate appears to be renewing as scheduled but browsers are not picking up the renewal. I’ve asked for help on this topic before and thought it was solved but once again browsers are not getting my renewed certificate.

Here is a link to the previous thread: SSL certificate renewed but browsers not updating with new certificate

My domain is: vestasit.com

I ran this command: sudo certbot certificates

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Found the following certs:
Certificate Name: vestasit.com
Domains: vestasit.com www.vestasit.com
Expiry Date: 2020-11-16 05:02:36+00:00 (VALID: 83 days)
Certificate Path: /etc/letsencrypt/live/vestasit.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/vestasit.com/privkey.pem

My web server is (include version): ubuntu 18.04.3 LTS

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

My hosting provider, if applicable, is: Google Cloud Platform

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

The version of my client is: 0.31.0

Output of command cat /etc/cron.d/certbot:
/etc/cron.d/certbot: crontab entries for the certbot package
Upstream recommends attempting renewal twice a day
Eventually, this will be an opportunity to validate certificates
haven’t been revoked, etc. Renewal will only occur if expiration
is within 30 days.
Important Note! This cronjob will NOT be executed if you are
running systemd as your init system. If you are running systemd,
the cronjob.timer function takes precedence over this cronjob. For
more details, see the systemd.timer manpage, or use systemctl show
certbot.timer.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
0 */12 * * * root test -x /usr/bin/certbot -a ! -d /run/systemd/system && perl -e ‘sleep int(rand(43200))’ && certbot -q renew

HOWEVER, I just noticed that when I use the command sudo crontab -e I have a slightly different command line which includes a hook for restarting the server (I think):
0 */12 * * * root test -x /usr/bin/certbot -a ! -d /run/systemd/system && perl -e ‘sleep int(rand(43200))’ && certbot -q renew --deploy-hook “/usr/local/lsws/bin/lswsctrl restart”

Could this discrepancy be the reason my SSl cert is not being picked up by browsers? How to I correct this?

Any help is appreciated!

1 Like
2

Could be. By the certbot certificates you saw your certificate was renewed properly. This could have been done by either certbot renew commands. However, your second crontab also includes a --deploy-hook which reloads your webserver. (Or actually it restarts it, which could give a small amount of downtime. Not sure if reloading is possible.)

It could be your webserver hasn't been reloaded/restarted this time too because for some reason the first cronjob ran, renewed your certificate and prevented the second cronjob from renewing and consequentially restarting your webserver.

It should be perfectly possible to remove /etc/cron.d/certbot and leave the one you saw through crontab -e. It might have been installed through some kind of package from your package manager though, so it might come back, I dunno.. For now, I would advice to run /usr/local/lsws/bin/lswsctrl restart manually once.

1 Like
3

You need to find which users are running certbot in cron.
Merge/reduce that down to just one user (preferably root user).
Then there you can run the correct certbot command.

4

I think this latter command is invalid in this context! There are two different formats for crontab files, one for a per-user crontab and one for a systemwide crontab.

The systemwide version (historically for /etc/crontab and also nowadays for files in /etc/cron.d) specifies a username to run the job as, like

min hour day month dayofweek user command

The per-user version (including for the root user's personal crontab) does not specify a username, and looks like

min hour day month dayofweek command

Note that it has one fewer field! That makes me expect that root in the second crontab you mention will be misinterpreted as the command name, in which case this job would probably fail every time (as there is no command called root). Maybe you could look in your log files and see if you can find errors related to this.

2 Likes
5

I have virtually no experience in this field, except what I’ve learned trying to figure out how to make this certificate renew. How would I go about determining which users are running certbot in cron and how would I merge/reduce that to just one?

If I cat /etc/cron.d/certbot I get the same print out as if I sudo cat /etc/cron.d/certbot. However, when I contab -e it’s different than if I sudo crontab -e. The root crontab -e contains the renew and restart command as mentioned above but the non-root user crontab -e does not contain any commands. Would this be causing a problem?

Thanks!

1 Like
6

crontab -u <user> -l
To review all crontab entries, insert all user names individually; like:
crontab -u root -l

By editing them.
Deleting the ones you don't need and leaving only the one you do need (and the way you need it).

1 Like
7

crontab -e will edit the cron list for the currently logged on user.
sudo crontab -e will edit the cron list for the root/super user.

8

Thank you for the instructions. I followed the command for all users and only root has a crontab. So I’m at a loss again.

How would I add the server restart command to the cron.d/certbot file? I only know how to get into and edit the contab, but not the cron.d/certbot.

9

These two statements are a contradiction:

10

crontab -e (non-root user) is just the basic document, with no scripts in it. So when I try to crontab -u <myusername> -l it said there were no documents.

11

I’m still unable to figure out why browsers are not picking up the new certificates and assume that it’s because the server is not reloading.

I ran sudo certbot renew --dry-run and get the following:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/vestasit.com.conf

Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for vestasit.com
http-01 challenge for www.vestasit.com
Waiting for verification…
Cleaning up challenges
Dry run: skipping deploy hook command: /usr/local/lsws/bin/lswsctrl reload

new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/vestasit.com/fullchain.pem

** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/vestasit.com/fullchain.pem (success)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry

Note that there is a deploy hook to reload the server. I tried running that line on its own and it did reload the server and my certificates were picked up by the browsers. But why is this hook not running/working when the certificates renew? It seems that I have to manually reload the server every 2 months.

Please help!

12

The skipping is by design, because you're doing a dry run. When certbot will actually renew your certificate, it should reload the webserver properly.

1 Like
13

It only executes on an actual cert deployment - which should regularly happen every 60 days.

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.