Unable to renew my certificate with certbot

Help
1

Hi there, Let's Encrypt community. I'm currently unable to renew my certificate with certbot and I was hoping you could help me.

My domain is:
support.uranie-conseil.fr

I ran this command:
sudo certbot renew

It produced this output:

uranie@maia:~$ sudo certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/support.uranie-conseil.fr.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for support.uranie-conseil.fr

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: support.uranie-conseil.fr
Type: unauthorized
Detail: 90.121.14.169: Invalid response from http://support.uranie-conseil.fr/.well-known/acme-challenge/eABGW0eCJXeSB7INMnzbzMbJClCs711qRhrlQZybfRE: 400

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 support.uranie-conseil.fr with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/support.uranie-conseil.fr/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
uranie@maia:~$

My web server is (include version):

uranie@maia:~$ sudo apachectl -V
Server version: Apache/2.4.56 (Debian)
Server built: 2023-04-02T03:06:01
Server's Module Magic Number: 20120211:126
Server loaded: APR 1.7.0, APR-UTIL 1.6.1, PCRE 8.45 2021-06-15
Compiled using: APR 1.7.0, APR-UTIL 1.6.1, PCRE 8.39 2016-06-14
Architecture: 64-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_PROC_PTHREAD_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"
uranie@maia:~$

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

uranie@maia:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
uranie@maia:~$

My hosting provider, if applicable, is:
https://www.amen.fr/

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):

uranie@maia:~$ sudo certbot --version
certbot 2.7.0
uranie@maia:~$
2

The 400 in the above error is an HTTP error code. I also get a 400 just trying to view your home page using HTTP (port 80).

The error message from your system says you have port 80 configured to require HTTPS but it should only be handling HTTP requests.

Please show result of this

sudo apachectl -t -D DUMP_VHOSTS

Below is the error for your home page

curl -i http://support.uranie-conseil.fr
HTTP/1.1 400 Bad Request
Server: Apache/2.4.56 (Debian)

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>400 Bad Request</title>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
 Instead use the HTTPS scheme to access this URL, please.<br />
3 Likes
3

Hello MikeMcQ and thank you for your reply.

Here's the output of sudo apachectl -t -D DUMP_VHOSTS:

uranie@maia:~$ sudo apachectl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:443                  support.uranie-conseil.fr (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
*:80                   support.uranie-conseil.fr (/etc/apache2/sites-enabled/000-default.conf:1)
uranie@maia:~$

Indeed when I try to access my home page through HTTP, I get the same error message you mentioned.

Edit: Thank you Osiris for the formatting :slight_smile:

2 Likes
4

Now can you show the contents of that file?

Please add 3 backticks before and after to preserve all the info like
```
contents of file
```

2 Likes
5

Thanks for the clarification regarding the formatting, here goes:

uranie@maia:~$ sudo cat /etc/apache2/sites-enabled/000-default.conf
<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 www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/glpi/public
        <Directory /var/www/html/glpi/public>
        #Options Indexes FollowSymLinks
        #AllowOverride All
        Require all granted
        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule ^(.*)$ index.php [QSA,L]
        </Directory>

        # 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


ServerName support.uranie-conseil.fr
RewriteCond %{SERVER_NAME} =support.uranie-conseil.fr
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
uranie@maia:~$
1 Like
6

I don't see anything in that to cause the 400 error.

You should check any network routing. Make sure incoming requests on port 80 get directed to this Apache on port 80.

If you were home-based, I would say check your router's NAT. But, maybe your hosting service has a similar routing option so check that.

You may even need to ask your hosting provider about that.

One way to help diagnose why the request arrives in the wrong place is to change the CustomLog to be a unique name in each VirtualHost. Then, try the HTTP request and check both logs. Maybe incoming HTTP requests are being sent to port 443 in Apache? Anyway, these are the kinds of things that cause this.

2 Likes
7

Oh, perhaps this is helpful ... I tried using HTTPS but to port 80 and got the html page with the below title. Do you recognize that? It looks like some sort of login page.

(HTTPS to port 80 should fail but does not)
curl -i https://support.uranie-conseil.fr:80
HTTP/1.1 200 OK
Server: Apache/2.4.56 (Debian)
Set-Cookie: glpi_3f946f74140a3178722cb675d5bf6b47=u0jku5rgihqfuik8fn4bp8k79g; path=/; secure; HttpOnly

<!DOCTYPE html>
<html lang="fr" >
<head>
   <title>Authentification - GLPI</title>
2 Likes
8

Yes I do, this machine is hosting a GLPI server and logging in is the first thing any user needs to do when arriving on the home page. Would you happen to have any idea what would cause Apache to use the port 80 for HTTPS traffic?

9

Just the reasons I already stated ... that something before Apache is wrongly directing port 80 requests to Apache on port 443.

You could confirm this by changing the names of your logs for each VirtualHost and see if an HTTP request arrives in your port 443 VirtualHost. I think it will so then work with your hosting service and its network config to see why that is happening.

2 Likes
10

Thank you so much, discussing this issue with you allowed me to eliminate the possibility of a faulty Apache configuration. I then spoke with my colleague in charge of networking and it turns out that, in my first message, the IP 90.121.14.169 is incorrect. The traffic should not end up there. We are currently checking what's causing this issue and I will update this post as soon as we find out.

2 Likes
11

All right, we found the source of this issue. There is indeed an equipment on our network which enforce a rule so that all port 80 requests on our GLPI server are being redirected to its port 443. We are going to make sure the team in charge of this equipment modify this configuration. Then my certificate renewal should work properly. If that's the case, I'll post a new message here to ask the moderators to close this thread. If it still does not work, then I'll be back with more questions. :sweat_smile:

Again, thank you very much for your help, MikeMcQ. :pray:

As for me, today I learned that in order for a Let's Encrypt certificate issued with certbot to be able to renew itself, I need my port 80 to function properly and not have its traffic redirected to the port 443. :nerd_face:

3 Likes
12

Not just for Certbot, but also for users trying to get to your website by typing in the URL, which usually does not include the https:// part. While Chrome will try HTTPS on port 443 first, other browsers as far as I know do not. So the user would see an error, probably not something you'd want.

Note that a HTTP-level redirect from HTTP to HTTPS is obviously something you'd want, you should never haphazardly point port 80 to 443 on the TCP level..

4 Likes
13

Hello Osiris and thank you for your reply. I usually handle these parameters via the configuration files of Apache but my colleague insisted on configuring that redirection on a specific network equipment. As I have less experience than him, I just put my trust in his way of doing things. Discussing with MikeMcQ and you gave me the confirmation that I shouldn't have done that.

Trust me, I take good note of your advice and will make sure the situation which led me to post here won't happen ever again. :saluting_face:

Anyway, the faulty configuration is now gone and everything is functioning as it should:

uranie@maia:~$ sudo certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/support.uranie-conseil.fr.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for support.uranie-conseil.fr
Reloading apache server after certificate renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded: 
  /etc/letsencrypt/live/support.uranie-conseil.fr/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
uranie@maia:~$

Thank you guys very much for your help and have a good one. This thread may now be closed. :slightly_smiling_face:

4 Likes
14

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