Two VirtualHost on one Apache 2, letsencrypt redirects both to one

My domain is: and

I ran this command: certbot --apache and selected certificates for the new site It ran fine but "" now goes to "" (but with wrong certificate) ( is the existing site with https which works fine). It seems as certbot does not recognize that there are two virtualhost on one server.
apachectl -S gives this:

[Sat Mar 05 14:57:08.365204 2022] [so:warn] [pid 967149] AH01574: module dav_module is already loaded, skipping
VirtualHost configuration: is a NameVirtualHost
default server (/etc/apache2/sites-enabled/001-dineputer-le-ssl.conf:2)
port 443 namevhost (/etc/apache2/sites-enabled/001-dineputer-le-ssl.conf:2)
port 443 namevhost (/etc/apache2/sites-enabled/001-dineputer-le-ssl.conf:22)
*:443 (/etc/apache2/sites-enabled/002-holeinvoid-le-ssl.conf:2)
*:80 is a NameVirtualHost
default server localhost (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost localhost (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost (/etc/apache2/sites-enabled/001-dineputer.conf:1)
port 80 namevhost (/etc/apache2/sites-enabled/002-holeinvoid.conf:1)
port 80 namevhost (/etc/apache2/sites-enabled/002-holeinvoid.conf:11)
port 80 namevhost (/etc/apache2/sites-enabled/002-holeinvoid.conf:21)
port 80 namevhost (/etc/apache2/sites-enabled/002-holeinvoid.conf:31)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
PidFile: "/var/run/apache2/"
User: name="www-data" id=33
Group: name="www-data" id=33
My web server is (include version):

The operating system my web server runs on is (include version):
Server version: Apache/2.4.41 (Ubuntu)
Server built: 2022-01-05T14:49:56

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 1.24.0

I solved this, seems certbot did not manage to edit my virtualhost config files properly, after I manually changed the virtualhost host file in the second not working https virtualhost it works. I had to change
<VirtualHost *:443> to <VirtualHost>.

That's not supposed to help. You should edit the ServerName directive inside the block instead.


It worked because now all your port 443 VirtualHosts are IP based hosts. You would be better off with all of them as Named VirtualHosts like you have with your port 80 servers.

See Apache docs but really all port 443 should just be VirtualHost *:443

Mixing some IP hosts and some Name hosts is very complex and often leads to poor results


Yea I thought it was kind of bad. But problem is <VirtualHost *:443> with Servername did not work, while <VirtualHost> works. After reading your comments and thinking a bit I checked my config for the, and that one also had virtualhost So I changed BOTH to use *:443 and corresponding servername and now it works. Only God knows whereever I added the, or Certbot did it.

Yes, because your first port 443 server:

VirtualHost configuration: is a NameVirtualHost
default server (/etc/apache2/sites-enabled/001-dineputer-le-ssl.conf:2)

is 'latching' any requests to that IP since that's how you defined it. This is how Apache works when mixing IP and name based. All your port 443 servers should be IP or all be named based. I suggest changing them all to be *:443 and using ServerName and ServerAlias as needed. But, if you want to leave them all as IP that works but is often confusing. It is technically possible to have a mix of IP and name but that is very complex and for rare situations.


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