Certbot fails with "Can't find virtual host" error

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:
bree.org.uk
I ran this command:
certbot -v --apache -d bree.org.uk
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Requesting a certificate for bree.org.uk
Performing the following challenges:
http-01 challenge for bree.org.uk
Cleaning up challenges
Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.
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):
Apache 2.4.57-1
The operating system my web server runs on is (include version):
Fedora 38
My hosting provider, if applicable, is:
n/a
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.5.0

Snippet from the certbot error log:

2023-04-20 12:47:12,518:DEBUG:acme.client:Storing nonce: F9779Bm_4QGGQgbpAODhCeHouEG9L4rdMHY1WTgTkixofps
2023-04-20 12:47:12,519:INFO:certbot._internal.auth_handler:Performing the following challenges:
2023-04-20 12:47:12,519:INFO:certbot._internal.auth_handler:http-01 challenge for bree.org.uk
2023-04-20 12:47:12,528:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/certbot/_internal/auth_handler.py", line 88, in handle_authorizations
resps = self.auth.perform(achalls)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/certbot_apache/_internal/configurator.py", line 2474, in perform
http_response = http_doer.perform()
^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/certbot_apache/_internal/http_01.py", line 66, in perform
self._mod_config()
File "/usr/lib/python3.11/site-packages/certbot_apache/_internal/http_01.py", line 102, in _mod_config
selected_vhosts += self._relevant_vhosts()
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/certbot_apache/_internal/http_01.py", line 145, in _relevant_vhosts
raise errors.PluginError(
certbot.errors.PluginError: Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.

Hi @pjoc and Welcome to the Community!

Is telling you what is needed.
What says

apache2ctl -t -D DUMP_VHOSTS

That should shed some light on your issue.
It also should get you on your way to a solution. on my way to med appt

4 Likes

Thanks. Fedora has apachectl (not apache2ctl) but I get:

$ apachectl -t -D DUMP_VHOSTS
Passing arguments to httpd using apachectl is no longer supported.
You can only start/stop/restart httpd using this script.
To pass extra arguments to httpd, see the httpd.service(8)
man page.

The httpd.service man page is unenlightening about how to do this.

I should mention that httpd is running and I can browse to port 80 manually, including from outside my local net.

It's also surprising that the Certbot error gives a trace dump in the log, which to me would indicate a code bug of some sort. Maybe I'm wrong about that.

2 Likes

You should probably be able to use httpd -t -D DUMP_VHOSTS I think.

Might be, but as long as it doesn't show up outside the log I'm not that worried.

4 Likes

I think using:

might have to do with that extra logging.

2 Likes

I don't think -v has effect on the contents of letsencrypt.log, only on the CLI output.

3 Likes

I may be wrong...
But I can't help what

Easy to test:
Does it happen when not using "-v"?

2 Likes

httpd -t -D DUMP_VHOSTS

VirtualHost configuration:
*:443 bree.org.uk (/etc/httpd/conf.d/ssl.conf:56)

poc

It does.

poc

1 Like

Only 443 vhost in use.

So, this is correct:

3 Likes

Yes, I noticed that. Nevertheless, port 80 is open and I can browse to it. I assume there's something wrong with my httpd config file but can't see what it is. I'm basically following the instructions at:

I see that too:
[very stange]

curl -Ii http://bree.org.uk/
HTTP/1.1 200 OK
Date: Thu, 20 Apr 2023 21:17:50 GMT
Server: Apache/2.4.57 (Fedora Linux) OpenSSL/3.0.8     <<<<<<< SAME 
Last-Modified: Tue, 21 Mar 2023 15:38:58 GMT
ETag: "a7c-5f76ad7858880"                              <<<<<<< SAME 
Accept-Ranges: bytes
Content-Length: 2684
Content-Type: text/html; charset=UTF-8

curl -Iik https://bree.org.uk/
HTTP/1.1 200 OK
Date: Thu, 20 Apr 2023 21:17:53 GMT
Server: Apache/2.4.57 (Fedora Linux) OpenSSL/3.0.8     <<<<<<< SAME 
Last-Modified: Tue, 21 Mar 2023 15:38:58 GMT
ETag: "a7c-5f76ad7858880"                              <<<<<<< SAME 
Accept-Ranges: bytes
Content-Length: 2684
Content-Type: text/html; charset=UTF-8

If all else fails... reboot

3 Likes

If all else fails... reboot

I've rebooted several times since first posting this issue. Makes no difference.

2 Likes

Please show output of:
netstat -pant | grep -E ':80|:443'

2 Likes

Apache doesn't need a virtual host to actually serve content over HTTP (a global DocumentRoot suffices), but Certbot does want one. For e.g. redirects et cetera.

4 Likes
$ sudo netstat -pant | grep -E ':80|:443'
tcp        0      0 192.168.178.69:56921    72.247.176.74:80        TIME_WAIT   -                   
tcp        0      0 192.168.178.69:42564    216.58.212.206:443      TIME_WAIT   -                   
tcp        0      0 192.168.178.69:49110    142.250.200.42:443      ESTABLISHED 2859/rclone         
tcp        0      0 192.168.178.69:37070    54.216.77.33:443        ESTABLISHED 1704/Plex Media Ser 
tcp        0      0 192.168.178.69:53790    64.71.144.203:443       ESTABLISHED 26550/chrome --type 
tcp        1      0 192.168.178.69:52318    172.64.146.103:443      CLOSE_WAIT  1817/Plex DLNA Serv 
tcp        0      0 192.168.178.69:46516    143.244.38.137:443      ESTABLISHED 26550/chrome --type 
tcp        0      0 192.168.178.69:59546    192.168.178.53:8009     ESTABLISHED 26550/chrome --type 
tcp        0      0 192.168.178.69:38634    178.79.179.11:443       ESTABLISHED 1704/Plex Media Ser 
tcp        0      0 192.168.178.69:36712    74.125.133.188:443      ESTABLISHED 26550/chrome --type 
tcp        0      0 192.168.178.69:54452    23.20.112.133:443       ESTABLISHED 26550/chrome --type 
tcp        1      0 192.168.178.69:52328    172.64.146.103:443      CLOSE_WAIT  1817/Plex DLNA Serv 
tcp        1     25 192.168.178.69:42780    54.216.77.33:443        LAST_ACK    -                   
tcp        0      0 192.168.178.69:33700    172.217.16.229:443      ESTABLISHED 26550/chrome --type 
tcp        0      0 192.168.178.69:46606    142.250.180.14:443      TIME_WAIT   -                   
tcp        0      0 192.168.178.69:58222    52.168.117.169:443      ESTABLISHED 26550/chrome --type 
tcp        0      0 192.168.178.69:48136    216.58.212.202:443      ESTABLISHED 2859/rclone         
tcp        0      0 192.168.178.69:53828    172.217.169.74:443      ESTABLISHED 3463/rclone         
tcp        0      0 192.168.178.69:34216    18.244.140.87:443       ESTABLISHED 26550/chrome --type 
tcp        0      0 192.168.178.69:55624    104.18.13.33:443        ESTABLISHED 26550/chrome --type 
tcp        0      0 192.168.178.69:45552    157.240.221.60:443      ESTABLISHED 26550/chrome --type 
tcp        0      0 192.168.178.69:48756    54.216.77.33:443        ESTABLISHED 1704/Plex Media Ser 
tcp       25      0 192.168.178.69:40380    34.251.159.167:443      CLOSE_WAIT  1817/Plex DLNA Serv 
tcp        0      1 192.168.178.69:42898    178.79.179.11:443       FIN_WAIT1   -                   
tcp        1      0 192.168.178.69:52330    172.64.146.103:443      CLOSE_WAIT  1817/Plex DLNA Serv 
tcp6       0      0 :::443                  :::*                    LISTEN      16208/httpd

The server isn't running on port 80. Does your firewall redirects port 80 to another server? Or in case of same server, to another port but not on port 80?

1 Like

can we try bring up the nfqueue plug-in and bypass most config?

if it hit the server this will be surefire way to catch it as it run on preroute

3 Likes

The firewall directs 80->80 and 443->443. I notice that the netstat output shows port 80 for tcp6, which as far as I know I don't run. The fact remains that from outside the network I can browse to port 80, and port 443 gives me an SSL challenge as it should.

Try:
netstat -pant | grep -i 'listen'

2 Likes