Challenge failed

Help
1

Hi,

Hello, unfortunately, I find too many posts on the topic, but I can't find anything specific that helps me. I am unable to create a certificate using Certbot.
Despite having the firewall disabled, I still get a time-out. Interestingly, I can access the FETCH URL in the browser and see the correct token. I'm not sure if it matters, but the server is not reachable via IPv4. I have an AAAA record under my domain pointing to my server in my home network.
Does anyone have an idea of what else I could check?
Here you can find my certbot log. I'm wondering, it ends with a traceback I can't read.

My domain is:

> nextcloud.wref.de

I ran this command: s

> udo certbot certonly --apache -d "nextcloud.wref.de" --debug-challenges --dry-run -v

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Simulating a certificate request for nextcloud.wref.de
Performing the following challenges:
http-01 challenge for nextcloud.wref.de

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA.

The following URLs should be accessible from the internet and return the value
mentioned:

URL:
http://nextcloud.wref.de/.well-known/acme-challenge/FTzeYTH6wLKI_ehLeqXa_HHPPQWk0mbH2mbQUG7w3_4
Expected value:
FTzeYTH6wLKI_ehLeqXa_HHPPQWk0mbH2mbQUG7w3_4.iMCLnutg62tG3mlwZLUYIX7-qzaRKuL0emaVxuomnB8
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Waiting for verification...
Challenge failed for domain nextcloud.wref.de
http-01 challenge for nextcloud.wref.de

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
  Domain: nextcloud.wref.de
  Type:   connection
  Detail: 2a00:6020:4196:ca00:3bee:c98b:d966:9e3d: Fetching http://nextcloud.wref.de/.well-known/acme-challenge/FTzeYTH6wLKI_ehLeqXa_HHPPQWk0mbH2mbQUG7w3_4: Timeout during connect (likely firewall problem)

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.

Cleaning up challenges
Some challenges have failed.
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.

My web server is (include version):
Server version: Apache/2.4.62 (Debian)

The operating system my web server runs on is (include version):
Linux nextcloud 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux

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.1.0

2

in addition, my apache-site-conf from sites-enabled:

<VirtualHost *:80>
  DocumentRoot /var/www/nextcloud/
  ServerName  nextcloud.wref.de

  <Directory /var/www/nextcloud/>
    Require all granted
    AllowOverride All
    Options FollowSymLinks MultiViews

    <IfModule mod_dav.c>
      Dav off
    </IfModule>
  </Directory>
</VirtualHost>

Theres no further config in sites-enabled.

3

In addition to my post above:
The page request for http://nextcloud.wref.de/.well-known/acme-challenge/FTzeYTH6wLKI_ehLeqXa_HHPPQWk0mbH2mbQUG7w3_4 results in the output FTzeYTH6wLKI_ehLeqXa_HHPPQWk0mbH2mbQUG7w3_4.iMCLnutg62tG3mlwZLUYIX7-qzaRKuL0emaVxuomnB8

4

Double check that http (tcp port 80) requests work from a public network (e.g. using phone data), not just internally on your own network.

4 Likes
7

I'm not sure if this (alone):

will cover this request:

You may need another copy of that vhost with this:
<VirtualHost [::]:80>

OR...
Maybe they can be combined as:
<VirtualHost *:80 [::]:80>

3 Likes
8

It does on my Apache. And in my ports.conf I also just have "plain" listen statements for the ports (nothing unique for IPv4 / 6).

I think more likely a firewall problem. Maybe it does not have a needed rule for IPv6?

nginx for sure needs IPv4/6 specific listen statements in its server blocks. Apache not so much.

5 Likes
9

Confirming from the Apache docs what @MikeMcQ has stated.

The Listen directive tells the server to accept incoming requests on the specified port or address-and-port combination. If only a port number is specified, the server listens to the given port on all interfaces. If an IP address is given as well as a port, the server will listen on the given port and interface.

Multiple Listen directives may be used to specify a number of addresses and ports to listen to. The server will respond to requests from any of the listed addresses and ports.

For example, to make the server accept connections on both port 80 and port 8000, use:

Listen 80
Listen 8000

To make the server accept connections on two specified interfaces and port numbers, use

Listen 192.170.2.1:80
Listen 192.170.2.5:8000

IPv6 addresses must be surrounded in square brackets, as in the following example:

Listen [2001:db8::a00:20ff:fea7:ccea]:80

https://httpd.apache.org/docs/current/mod/mpm_common.html#listen

3 Likes
10

But...
Did we ever see the Listen statement(s)?

3 Likes
11

Not that I've seen. :thinking:

3 Likes
12

No, they may have "latched" their ports.conf listen for port 80 to a specific IPv4 address only

I don't recall ever seeing that happen on this forum but always a first :slight_smile: Would seem especially odd that they would do that for a DNS setup for IPv6 only but we've seen stranger.

Now that it's working maybe @herates could explain what the cause was? And mark any post that helped resolve it.

4 Likes
13

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