Renewal fails but no changes on server

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. crt.sh | 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: cumulus.myftp.org

I ran this command: cetbot renew

It produced this output:

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: cumulus.myftp.org
Type: unauthorized
Detail: 188.136.104.165: Invalid response from http://cumulus.myftp.org/.well-known/acme-challenge/FsFCgSRqyRFzmmDUEvM4V8NSgbOheTrJQtlaFysObyc: 404

My web server is: Apache 2.4.58

The operating system my web server runs on is: Ubuntu 24.04.4 LTS

My hosting provider, if applicable, is: self-hosted

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 (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.9.0

I have been running Nextcloud on Ubuntu since for quite some time, first on an UCS server which did pretty everything on its own after the first setup.

After an upgrade was not possible (for whichever reason)I switched to Ubuntu with a Nextcloud instance outside of UCS including Letsencrypt.

This worked fine since December.

The only changes I had in the last 2 weeks were some tweaks in Nextcloud/Apache regarding the errors "...well-known/webfinger..." etc.

I've never received an email that renewals didn't work but the certificates expired yesterday and I can't get to work the process again.

After the error message above I tried some things I found on the web regarding redirection which all didn't work.

I attach the main conf-files.

There are two other domains which get the same error.

I'm really at a loss here, so any help is much appreciated.
Thank you very much.

000-default.txt (1.4 KB)
cumulus.txt (1.1 KB)
cumulus-le-ssl.txt (1.7 KB)
default-ssl.txt (4.7 KB)

Let's Encrypt stopped sending emails some time last year; you should be running some monitoring system of your own to catch problems like this. But if your cert expired yesterday, and you have certbot running a renew task at least daily (or twice daily, as it configures itself by default), whatever changed would have been before 12 Feb.

6 Likes

I wasn't aware of that and thus will install some monitoring.

But alas this does not solve the problem.

I've looked further as I keep hitting "look at the rewrites..." hints in the web.

There's one in .htaccess in the Nextcloud root folder:

RewriteRule ^.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]

But I don't quite know where to put which files/folders so it works.

I have found some documentation on mod_md to get this to work inside Apache itself but don't quite get the configuration of this (regarding extra mod.conf and special settings in the site confs).

1 Like

The 404 is an http error code meaning Not Found. The Let's Encrypt server is sending that challenge to your system and your server replies not-found.

We need to look at the method used by Certbot to prepare your system for the challenge. Please show contents of the renewal file in /etc/letsencrypt/renewal for this domain.

Also please show output of this sudo certbot certificates

mod_md is a good choice. Hopefully you followed the official docs
Here: mod_md - Apache HTTP Server Version 2.4
And here: GitHub - icing/mod_md: Let's Encrypt (ACME) in Apache httpd ยท GitHub

I don't think it will be difficult to get Certbot working again. But the Apache reference is good for install instructions and reference and the github for "how to" guides

4 Likes

While searching for solutions it occured to me that at some point I specified the following in default-ssl.conf (without which apache won't start, so it seems I have to specify this here or somewhere else; this is one of the other domains on the server):

    SSLCertificateFile      /etc/letsencrypt/live/toko42.myftp.org/fullchain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/toko42.myftp.org/privkey.pem

sudo certbot certificates shows the following:
cumulus.myftp.org-renewal.txt (560 Bytes)

Certificate Name: cumulus.myftp.org
Serial Number: 6d5012c93d1d4bf8f2966debc6ec258a21c
Key Type: ECDSA
Domains: cumulus.myftp.org toko.myftp.org
Expiry Date: 2026-03-21 14:45:07+00:00 (VALID: 6 days)
Certificate Path: /etc/letsencrypt/live/cumulus.myftp.org/fullchain.pem
Private Key Path: /etc/letsencrypt/live/cumulus.myftp.org/privkey.pem

As I said, I was not certain on how to configure mod_md, I have stopped on that side for now as it seems to necessitate alteration of all site conf-files and at least a mod conf.

Right now I would prefer to "just solve it" :roll_eyes:

Thank you very much.

Sure. Right now your Apache config has various problems. HTTPS connections fail for either domain in the certificate you have.

I was also surprised to see you used the --apache option of Certbot yet have no lines in your Apache config that indicate "managed by Certbot". Usually the --apache option sets up your HTTPS VirtualHost on port 443 and, by default, adds suitable redirects in HTTP to redirect to HTTPS. It adds comments to those lines but there aren't any lines with that. That isn't why this isn't working but it is an odd thing to see.

Now, on to your problem. It looks like you have two VirtualHost both naming cumulous. And, no VirtualHost for port 80 that mentions toko42.

But, let us confirm what Apache thinks your VHost layout is. Please show output of this
sudo apache2ctl -t -D DUMP_VHOSTS

5 Likes

Also, when I asked for the output of certbot certificates you only showed one certificate and it wasn't the one above. What happened to it?

5 Likes

I have not altered the configuration regarding certbot, shouldn't the certbot installer have set this?
If not, please point me to some documentation.

https will probably not work because the certificates have expired...

I have amended the two confs which had cumulus in it, i.e. I have disabled one of them and added a toko42.conf.

Here's the dump:

VirtualHost configuration:
*:443                  is a NameVirtualHost
         default server cumulus.myftp.org (/etc/apache2/sites-enabled/cumulus-le-ssl.conf:6)
         port 443 namevhost cumulus.myftp.org (/etc/apache2/sites-enabled/cumulus-le-ssl.conf:6)
                 alias cumulus.myftp.org
         port 443 namevhost nextcloud.induhvidual.local (/etc/apache2/sites-enabled/default-ssl.conf:1)
         port 443 namevhost toko.myftp.org (/etc/apache2/sites-enabled/toko-le-ssl.conf:9)
                 alias toko.myftp.org
*:80                   is a NameVirtualHost
         default server cumulus.myftp.org (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost cumulus.myftp.org (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost cumulus.myftp.org (/etc/apache2/sites-enabled/cumulus.conf:7)
                 alias cumulus.myftp.org
         port 80 namevhost toko.myftp.org (/etc/apache2/sites-enabled/toko.conf:7)
                 alias toko.myftp.org

Thank you very much.

No. the HTTPS connection is failing as it doesn't support TLS connections. This is usually because your port routing is wrong or SSL isn't configured right in Apache. An expired cert allows the HTTPS connection and then informs of expired cert.

I will look at the rest shortly.

5 Likes

Maybe you'll need the apache conf as well for the full picture.

apache2.conf.txt (7.0 KB)

I appreciate this very much as I am mostly self-taught regarding this and probably miss some/many things.

Let's start with the problem of duplicated VHost for cumulus. You can see there is one VHost defined in 000-default.conf and another in cumulus.conf. Apache does not issue a warning or error for this but will not work correctly.

It looks like you intend the cumulus.conf to be the correct one. So, we can fix the duplication problem just by changing one line in your 000-default.conf file. It begins with this:

<VirtualHost *:80>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
ServerName cumulus.myftp.org

Change just the ServerName to this:

ServerName default.myftp.org

And reload Apache after. Check the update by showing this again
apache2ctl -t -D DUMP_VHOSTS

5 Likes

I reloaded and restarted apache2 but had to add the ServerName to default-ssl.conf, also.

*:443 is a NameVirtualHost
default server cumulus.myftp.org (/etc/apache2/sites-enabled/cumulus-le-ssl.conf:6)
port 443 namevhost cumulus.myftp.org (/etc/apache2/sites-enabled/cumulus-le-ssl.conf:6)
alias cumulus.myftp.org
port 443 namevhost default.myftp.org (/etc/apache2/sites-enabled/default-ssl.conf:1)
port 443 namevhost toko.myftp.org (/etc/apache2/sites-enabled/toko-le-ssl.conf:9)
alias toko.myftp.org
*:80 is a NameVirtualHost
default server default.myftp.org (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost default.myftp.org (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost cumulus.myftp.org (/etc/apache2/sites-enabled/cumulus.conf:7)
alias cumulus.myftp.org
port 80 namevhost toko.myftp.org (/etc/apache2/sites-enabled/toko.conf:7)
alias toko.myftp.org

It looks like there's a mention of nextcloud.induhvidual.local in default-ssl.conf but I can't find one but that's the name I set in the global configuration of Apache.

What happened to the cert I asked about in this post

4 Likes

Sorry, I copied the output but forgot to paste...

Found the following certs:

  Certificate Name: cumulus.myftp.org
    Serial Number: 6d5012c93d1d4bf8f2966debc6ec258a21c
    Key Type: ECDSA
    Domains: cumulus.myftp.org toko.myftp.org
    Expiry Date: 2026-03-21 14:45:07+00:00 (VALID: 6 days)
    Certificate Path: /etc/letsencrypt/live/cumulus.myftp.org/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/cumulus.myftp.org/privkey.pem

  Certificate Name: toko.myftp.org
    Serial Number: 66b20a5f8b086bfc7c133a975e8b3082680
    Key Type: ECDSA
    Domains: toko.myftp.org
    Expiry Date: 2026-03-24 09:09:24+00:00 (VALID: 9 days)
    Certificate Path: /etc/letsencrypt/live/toko.myftp.org/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/toko.myftp.org/privkey.pem

  Certificate Name: toko42.myftp.org
    Serial Number: 5328d95187d0d52e938fa804290112353e5
    Key Type: ECDSA
    Domains: cumulus.myftp.org toko.myftp.org toko42.myftp.org
    Expiry Date: 2026-03-13 11:54:44+00:00 (INVALID: EXPIRED)
    Certificate Path: /etc/letsencrypt/live/toko42.myftp.org/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/toko42.myftp.org/privkey.pem
1 Like

Alright. You had a cert with all the names originally (toko42) and then it looks like you split your VHost configs. Which is fine but let's get the certs better aligned with your current VHost setup.

We'll focus on cumulus first. Show the output from this command:

sudo certbot certonly --dry-run --apache -d cumulus.myftp.org

This is only a test (--dry-run). I just want to see how your system handles this.

3 Likes

I have attached the log but truncated it for all earlier entries.

Here's the terminal's output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Simulating a certificate request for cumulus.myftp.org

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: cumulus.myftp.org
Type: unauthorized
Detail: 188.136.104.165: Invalid response from http://cumulus.myftp.org/.well-known/acme-challenge/7GaD8tgk7RnWRo7e044TCsWgVCJWHK8TS9UWe_mbx_k: 404

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Some challenges have failed.

Thanks again for your support.

letsencrypt.log.txt (21.8 KB)

The log shows that Certbot is making the expected changes to your system. Yet, Apache still returns a 404.

Can you rename that .htaccess file or otherwise disable it. At least just for a test. After that re-run the certbot --dry-run command again. The log info was helpful for last one but just the terminal output is enough for this time.

Also, HTTP requests to cumulus show a default Apache "home" page. Is that what you expect? I'd have thought it would show something else given you've had this running for a while now.

curl -i http://cumulus.myftp.org/ 

HTTP/1.1 200 OK
Date: Sat, 14 Mar 2026 16:36:46 GMT
Server: Apache/2.4.58 (Ubuntu)
Last-Modified: Sat, 03 Jan 2026 08:32:36 GMT

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
(... parts omitted ...)
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Apache2 Ubuntu Default Page: It works</title>
    <style type="text/css" media="screen">
3 Likes

Which .htaccess?

There are several ones:

  • /etc/apache2/sites-available
  • /var/www/html/nextcloud
  • /var/www/html/nextcloud/config
  • /var/www/html/nextcloud/data

Cumulus should show the landing page of Nextcloud (cumulus being the latin word for cloud).

I'm not aware that I have configured anything there.

toko/toko42 should show my personal page which has an index.html.

Any one that affects requests to that domain. Right off-hand I don't recall the precedence rules for .htaccess.

Any .htaccess redirect that affects URLs containing /.well-known/acme-challenge should be disabled

3 Likes