Renew failed. Error getting validation data


I made several attempts at renewing my domain certificates today, but they all failed.
The initial configuration of the certificates using certbot succeeded last october, and https access has been working fine since then. (But I only have 6 more days to go :frowning: )
This is the first time I'm attempting a renewal.

What should I do?

My domain is:

I ran this command:
certbot renew --apache

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

Processing /etc/letsencrypt/renewal/

Renewing an existing certificate for and 2 more domains

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Type: connection
Detail: Fetching Error getting validation data

Type: connection
Detail: Fetching Error getting validation data

Type: connection
Detail: Fetching Error getting validation data

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.

Failed to renew certificate with error: Some challenges have failed.

All renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/ (failure)

1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):
Server version: Apache/2.4.25 (Raspbian)
Server built: 2022-03-18T12:54:25

The operating system my web server runs on is (include version):
Raspbian 9.13 armv7l
Linux pi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

My hosting provider, if applicable, is:

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 2.8.0

Hi @jfl38, and welcome to the LE community forum :slight_smile:

Let's begin with the output of:
sudo apachectl -t -D DUMP_VHOSTS

And double check your public IP with the output of:


Thanks for the quick reply. Here's the output:

larvoire@pi:~ $ sudo apachectl -t -D DUMP_VHOSTS
[sudo] Mot de passe de larvoire :

VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost (/etc/apache2/sites-enabled/001-www.conf:1)
                 alias pi
                 alias www.pi
         port 80 namevhost (/etc/apache2/sites-enabled/002-jfl.conf:1)
                 alias jfl
*:443                  is a NameVirtualHost
         default server (/etc/apache2/sites-enabled/000-default.conf:1)
         port 443 namevhost (/etc/apache2/sites-enabled/000-default.conf:1)
         port 443 namevhost (/etc/apache2/sites-enabled/001-www.conf:6)
                 alias pi
                 alias www.pi
         port 443 namevhost (/etc/apache2/sites-enabled/002-jfl.conf:6)
                 alias jfl

larvoire@pi:~ $ curl

1 Like

Can you post the contents of that? Please add 3 backticks before and after so we don't lose some Apache tags to the forum's formatting. Like
contents of file

And, result of this too

curl -4
larvoire@pi:~ $ cat /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80 *:443>
        # 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.

        ServerAdmin webmaster@localhost
        # DocumentRoot /var/www/html
        Redirect 301 /

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
Include /etc/letsencrypt/options-ssl-apache.conf

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
larvoire@pi:~ $ curl -4

Okay. Before we dig into that can you post contents of the conf file in the /etc/letsencrypt/renewal folder? There should be only one but let me know if there is more than one. Probably

As an aside, this isn't the only problem or even the most important but you need to change

Redirect 301 /
Redirect 301 /

Right now requests like redirect incorrectly


It's the only file there:

larvoire@pi:~ $ cat /etc/letsencrypt/renewal/
# renew_before_expiry = 30 days
version = 2.7.1
archive_dir = /etc/letsencrypt/archive/
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/

# Options used in the renewal process
account = ff85ae985302e8c9975a568e8eed302e
authenticator = apache
installer = apache
server =
key_type = ecdsa

Also I changed the Redirect 301 target as you said, thanks.

1 Like

Thanks for all that.

A minor point first. You shouldn't add --apache when running certbot renew. The renew command uses the previously successful options in the renewal config. And, it does that for all cert profiles (you have just 1 anyway). But, any options on renew get applied to all the renewal config profiles which can be damaging. That's not a problem here since they match it is just bad practice to run renew with options except in specific cases.

Now, it really looks like something wrong with your port 80 network config.

Your VirtualHost for pi subdomain handles both port 80 and 443. That is unusual to have both in one VirtualHost but my own tests confirm Certbot works with it. So, your Apache config seems fine.

So, something else is causing an "empty reply" for http requests compared to https. You should check your router to ensure it is mapping port 80 inbound to your Apache as port 80. Also check for any firewall that might block port 80. Focus on things that might have changed since you got your first cert back on Oct19.

curl -i
curl: (52) Empty reply from server

curl -i
HTTP/1.1 301 Moved Permanently
Date: Wed, 10 Jan 2024 20:38:47 GMT
Server: Apache/2.4.25 (Raspbian)

You can see the "empty reply" happens even for requests to your "home" page so it is not unique to anything Let's Encrypt. But, the --apache plugin uses an HTTP Challenge so port 80 http requests must work.


I've fixed the http server, and the certificate update worked at last. :slight_smile:
Thanks for your help.

root@pi:/etc/apache2/sites-available# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for and 2 more domains
Reloading apache server after certificate renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded:
  /etc/letsencrypt/live/ (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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