`letsencrypt renew` says cert does not need renewal, but all clients show it's expired

[brampton]

My domain is: next.fluidlogic.io

I ran this command: (as root) letsencrypt renew

It produced this output:

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/next.fluidlogic.io.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/next.fluidlogic.io/fullchain.pem expires on 2020-07-06 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

My web server is (include version): nginx 1.17.8

The operating system my web server runs on is (include version): “Ubuntu 18.04.4 LTS” (server)

My hosting provider, if applicable, is: n/a - I’m self-hosting

I can login to a root shell on my machine: yes

I’m using a control panel to manage my site no

The version of my client is: certbot 0.31.0

Hi - just over a year ago I used the script made available by Carsten Rieger to install and harden a self-hosted Nextcloud instance. I’m running Nextcloud on a host on my home network, on a DMZ subnet. My ISP-provided router is in ‘bridge’ mode and I’m using IPFire as my router. It’s IPFire that requests a (dynamic) IP address from my ISP and which implements the DMZ on a specific NIC.

I’m using afraid.org to map my domain name next.fluidlogic.org to my dynamic ISP-provided external IP address.

Carsten’s script included setup for LetsEncrypt, which has worked more or less flawlessly since then, fetching updated certs. …(apart from a blip at the beginning of this year, which seems to have been down to some outages at LE - it was difficult to troubleshoot, but I got a new cert with a day or two to spare, not due to any technical marvelry on my part.)

There’s a cron job under root’s account that invokes a shell script weekly to check and optionally update my LE certs. It looks like this:

# cat /usr/local/src/install-nextcloud/maintenance/ssl-renewal.sh | nl
 1  ####
 2  # renew your letsencrypt ssl certificates weekly
 3  ######################################################################
 4  # PLEASE SUBSTITUTE username PROPERLY, e.g. nextcloud
 5  # PLEASE SUBSTITUTE Your Name PROPERLY, e.g. Carsten Rieger
 6  # PLEASE SUBSTITUTE your@email.com PROPERLY, e.g. info@nextcloud.com
 7  ######################################################################
 8  # create a cronjob, e.g.:
 9  # crontab -e
10  # @weekly /usr/local/src/install-nextcloud/ssl-renewal.sh > /home/manager/ssl-renewal.txt
11  ####

12  #!/bin/bash
13  CURRENT_TIME_FORMATE="%d.%m.%Y"
14  cd /etc/letsencrypt
15  echo "-------------------------------------"
16  echo "Renewal:"
17  letsencrypt renew
18  result=$(find /etc/letsencrypt/live/ -type l -mtime -1 )
19  if [ -n "$result" ]; then
20          /usr/sbin/service nginx stop
21          /usr/sbin/service mysql restart
22          /usr/sbin/service redis-server restart
23          /usr/sbin/service php7.3-fpm restart
24          /usr/sbin/service nginx restart
25  fi
26  mail -s "Renewal - $(date +$CURRENT_TIME_FORMATE)" -a "FROM: Nextcloud Root <root@orange-10>" ben@fluidlogic.org  < /home/manager/ssl-renewal.txt
27  exit 0

The important line is line 17.

As you can see from the output of the command at the top of this post, LE reckons the cert doesn’t need updating but any HTTP client complains. For example, here’s httipe fetching the main page:

$ http https://next.fluidlogic.io

http: error: SSLError: HTTPSConnectionPool(host='next.fluidlogic.io', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)'),)) while doing GET request to URL: https://next.fluidlogic.io/

I’m comfortable in Linux but a complete LE noob. I’d really appreciate some pointers to go about fixing this situation! Thank you in advance!

Regards
Brampton

[JuergenAuer]

Hi @brampton

that line

@brampton

/usr/sbin/service nginx restart

is required. May be that part didn't work (script too old).

So first idea. Restart your nginx manual.

[brampton]

Thank you @JuergenAuer - you’re a star. That’s solved it. My machine has an uptime of 69 days, which is unusual. Perhaps I’ve been masking a problem by rebooting after applying patches every few weeks.

# uptime
 17:51:42 up 69 days,  7:47,  1 user,  load average: 0.82, 1.13, 1.06