My domain is: Minux.cc
failed subdomains: sonata.minux.cc, jam21lee5.minux.cc
successfull subdomains: drinkalore.minux.cc, goldcube.minux.cc
I ran this command:
certbot --apache
It produced this output:
same output for each subdomain, claims success, installed certificate.
My web server is (include version):
Apache version 2.4.41
The operating system my web server runs on is (include version):
Ubuntu 20.04.6
My hosting provider, if applicable, is:
Contabo
I can login to a root shell on my machine (yes or no, or I don't know):
yes
control panel:no
Certbot: certbot 4.0.0
so,
some subdomains get the correct certificate, the newer ones i tried to add (sonata and jam21lee5) get a certificate for the main domain (minux.cc), there is no difference in the configuration between the working subdomains and the broken ones other then server name and webroot.
when using certbot, the server logs show that certbot is talking to the correct subdomain, it succeeds, installs the certificate in the expected location and name (/etc/letsencrypt/live/sonata.minux.cc/ with it's own certificate file), but the certificate that is generated keeps pointing to the main domain every time.
more information:
when trying to get a new certificate for jam21lee5.minux.cc, certbot returns the following output:
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/jam21lee5.minux.cc.conf)
What would you like to do?
1: Attempt to reinstall this existing certificate
2: Renew & replace the certificate (may be subject to CA rate limits)
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for jam21lee5.minux.cc
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/jam21lee5.minux.cc/fullchain.pem
Key is saved at: /etc/letsencrypt/live/jam21lee5.minux.cc/privkey.pem
This certificate expires on 2025-09-02.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for jam21lee5.minux.cc to /etc/apache2/sites-enabled/jam21lee5.minux.cc.conf
Your existing certificate has been successfully renewed, and the new certificate has been installed.
no, drinkalore.minux.cc works just fine, wich is why i'm stunned. some work but some don't, same config.
VirtualHost configuration:
161.97.181.152:80 is a NameVirtualHost
default server minux.cc (/etc/apache2/sites-enabled/minux.cc.conf:1)
port 80 namevhost minux.cc (/etc/apache2/sites-enabled/minux.cc.conf:1)
alias 161.97.181.152
port 80 namevhost drinkalore.vtchost.com (/etc/apache2/sites-enabled/drinkalore.vtchost.com.conf:1)
port 80 namevhost Goldcube.minux.cc (/etc/apache2/sites-enabled/goldcube.minux.cc.conf:1)
port 80 namevhost jam21lee5.minux.cc (/etc/apache2/sites-enabled/jam21lee5.minux.cc.conf:1)
port 80 namevhost minux.cc (/etc/apache2/sites-enabled/minux.cc.conf:1)
alias 161.97.181.152
port 80 namevhost minux.vtchost.com (/etc/apache2/sites-enabled/minux.vtchost.com.conf:1)
port 80 namevhost party.minux.cc (/etc/apache2/sites-enabled/party.minux.cc.conf:20)
port 80 namevhost Shorun.vtchost.com (/etc/apache2/sites-enabled/shorun.vtchost.com.conf:1)
port 80 namevhost sonata.minux.cc (/etc/apache2/sites-enabled/sonata.minux.cc.conf:1)
port 80 namevhost vtchost.com (/etc/apache2/sites-enabled/vtchost.conf:26)
port 80 namevhost wolfpak.vtchost.com (/etc/apache2/sites-enabled/wolfpack.vtchost.com.conf:1)
161.97.181.152:443 is a NameVirtualHost
default server minux.cc (/etc/apache2/sites-enabled/minux.cc.conf:28)
port 443 namevhost minux.cc (/etc/apache2/sites-enabled/minux.cc.conf:28)
alias 161.97.181.152
port 443 namevhost drinkalore.vtchost.com (/etc/apache2/sites-enabled/drinkalore.vtchost.com.conf:15)
port 443 namevhost Goldcube.minux.cc (/etc/apache2/sites-enabled/goldcube.minux.cc.conf:24)
alias goldcube
alias goldcube.vtchost.com
alias goldcube.minux.cc
port 443 namevhost jam21lee5.minux.cc (/etc/apache2/sites-enabled/jam21lee5.minux.cc.conf:18)
port 443 namevhost minux.cc (/etc/apache2/sites-enabled/minux.cc.conf:28)
alias 161.97.181.152
port 443 namevhost minux.vtchost.com (/etc/apache2/sites-enabled/minux.vtchost.com.conf:8)
port 443 namevhost party.minux.cc (/etc/apache2/sites-enabled/party.minux.cc.conf:1)
port 443 namevhost Shorun.vtchost.com (/etc/apache2/sites-enabled/shorun.vtchost.com.conf:11)
port 443 namevhost sonata.minux.cc (/etc/apache2/sites-enabled/sonata.minux.cc.conf:19)
port 443 namevhost vtchost.com (/etc/apache2/sites-enabled/vtchost.conf:1)
port 443 namevhost wolfpak.vtchost.com (/etc/apache2/sites-enabled/wolfpack.vtchost.com.conf:11)
Not from the public internet. Are you sure you don't mean this name?
This is not the main problem in any case.
In the above list you have 2 VirtualHosts for the same hostname. minux.cc appears first and also later. Oddly, they show the same line # in the same conf file.
My guess is you have a mix of IP based and Name-based VirtualHosts and the IP-based are taking precedence when Apache replies to requests. We can tell by looking at these files
you were on to something, we made some progress.
in apache main configuration i tried setting minux.cc as the main site before, wich it seems did actually work a bit to well, once that line was removed from the config it stopped taking the minux.cc main domain's certificate..
however....
now it's taking the certificate from "drinkalore.minux.cc" and applying it to "jam21lee5.minux.cc".. it's doing this with "sonata.minux.cc" as well, but for some reason "goldcube.minux.cc" and drinkalore itself work just fine???
the config files:
jam21lee5.minux.cc.conf:
<VirtualHost jam21lee5.minux.cc:80>
DocumentRoot /var/www/jamie
ServerAdmin shorun@vtchost.com
ErrorDocument 403 https://minux.cc/403.html
## Include /etc/apache2/badclients.conf
ServerName jam21lee5.minux.cc
<Directory "/var/www/jamie">
allow from all
Options None
Require all granted
</Directory>
HostNameLookups off
RewriteEngine on
RewriteCond %{SERVER_NAME} =jam21lee5.minux.cc
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost jam21lee5.minux.cc:443>
DocumentRoot /var/www/jamie
ServerAdmin shorun@vtchost.com
## ErrorDocument 403 https://minux.cc/403.html
ServerName jam21lee5.minux.cc
## Include /etc/apache2/badclients.conf
HostNameLookups off
<Directory "/var/www/jamie">
allow from all
Options None
Require all granted
</Directory>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/jam21lee5.minux.cc/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/jam21lee5.minux.cc/privkey.pem
</VirtualHost>
the marked out "includes" are filters for bad clients or requests, temp. disabled while this problem persists, tough this also applies to other sites that work just fine.
You should change all of your VirtualHost lines to use an asterisk instead of a name or IP address before the port. Do all for port 80 and for port 443
For example, your port 443 VHosts should look like this
<VirtualHost *:443>
I am fairly certain your mix of name-based VHosts and IP-based are causing the problem you see. It is rare to need IP-based VHosts but if you do require that you need to better organize your Apache config.
I think you still mean the cert from drinkalore.vtchost.com. I don't see a cert was ever issued for drinkalore.minux only drinkalore.vtchost.
if i remove the Virtual host names, would that not make all websites just conflict? those subdomains are different sites with different webroots and files, how would apache know what sites to present?
i tried a config without any ip based adresses, only names. same result.
the sites themself work, they present the page they should be, it's just the certificate that keeps getting it wrong.
Using asterisk as I explained is recommended in those Apache docs and is very common. This is a tried and true and better method.
Using domain names as you do can even cause problems as Apache has to do a DNS query to replace that name with an IP. A temp failure of DNS can cause problems for Apache.
ok, so managed to change the "default" website properly to minux.cc (it's taking it from the configs and the first one in the alphabet, wich is why "drinkalore" kept getting selected.
so now "minux.cc" is the actual default and it's back to selecting minux.cc for the certificate, but again, it does this ONLY for "sonata.minux.cc", "jam21lee5.minux.cc" and "party.minux.cc", all the others get the correct certificate...
VirtualHost configuration:
161.97.181.152:80 is a NameVirtualHost
default server minux.cc (/etc/apache2/sites-enabled/a-minux.cc.conf:1)
port 80 namevhost minux.cc (/etc/apache2/sites-enabled/a-minux.cc.conf:1)
port 80 namevhost drinkalore.vtchost.com (/etc/apache2/sites-enabled/drinkalore.vtchost.com.conf:1)
port 80 namevhost Goldcube.minux.cc (/etc/apache2/sites-enabled/goldcube.minux.cc.conf:1)
port 80 namevhost jam21lee5.minux.cc (/etc/apache2/sites-enabled/jam21lee5.minux.cc.conf:1)
port 80 namevhost minux.vtchost.com (/etc/apache2/sites-enabled/minux.vtchost.com.conf:1)
port 80 namevhost party.minux.cc (/etc/apache2/sites-enabled/party.minux.cc.conf:20)
port 80 namevhost Shorun.vtchost.com (/etc/apache2/sites-enabled/shorun.vtchost.com.conf:1)
port 80 namevhost sonata.minux.cc (/etc/apache2/sites-enabled/sonata.minux.cc.conf:1)
port 80 namevhost vtchost.com (/etc/apache2/sites-enabled/vtchost.conf:26)
port 80 namevhost wolfpak.vtchost.com (/etc/apache2/sites-enabled/wolfpack.vtchost.com.conf:1)
161.97.181.152:443 is a NameVirtualHost
default server minux.cc (/etc/apache2/sites-enabled/a-minux.cc.conf:27)
port 443 namevhost minux.cc (/etc/apache2/sites-enabled/a-minux.cc.conf:27)
port 443 namevhost drinkalore.vtchost.com (/etc/apache2/sites-enabled/drinkalore.vtchost.com.conf:15)
port 443 namevhost Goldcube.minux.cc (/etc/apache2/sites-enabled/goldcube.minux.cc.conf:24)
port 443 namevhost jam21lee5.minux.cc (/etc/apache2/sites-enabled/jam21lee5.minux.cc.conf:17)
port 443 namevhost minux.vtchost.com (/etc/apache2/sites-enabled/minux.vtchost.com.conf:8)
port 443 namevhost party.minux.cc (/etc/apache2/sites-enabled/party.minux.cc.conf:1)
port 443 namevhost Shorun.vtchost.com (/etc/apache2/sites-enabled/shorun.vtchost.com.conf:11)
port 443 namevhost sonata.minux.cc (/etc/apache2/sites-enabled/sonata.minux.cc.conf:22)
port 443 namevhost vtchost.com (/etc/apache2/sites-enabled/vtchost.conf:1)
port 443 namevhost wolfpak.vtchost.com (/etc/apache2/sites-enabled/wolfpack.vtchost.com.conf:11)
Well, nothing is working from the public internet right now.
When you say these are "working" or "not working" do you mean from the public internet or your local?
Some examples right now
curl -i https://jam21lee5.minux.cc
curl: (7) Failed to connect to jam21lee5.minux.cc port 443 after 97 ms: Connection refused
curl -i http://sonata.minux.cc
curl: (7) Failed to connect to sonata.minux.cc port 80 after 132 ms: Connection refused
curl -i https://sonata.minux.cc
curl: (7) Failed to connect to sonata.minux.cc port 443 after 96 ms: Connection refused
curl -i http://minux.cc
curl: (7) Failed to connect to minux.cc port 80 after 97 ms: Connection refused
curl is one of the things that fail2ban will catch because bots keep using it to try to obtain things like wordpress config or "login.asp", you got filtered out and that's why.
i looked if i could find when you got blocked but you aren't the only one trying to use curl, i got no clue wich one you are....
Apache is not selecting the correct virtual host for the incoming HTTPS request. If it would it would use the correct certificate. You likely are seeing a browser regress to using HTTP when it finds that the HTTPS request has an invalid certificate.
Browsers often hide such underlying problems which is why tools like curl are so useful for diagnostic purposes.
I don't have time right now to set up different tooling to look at this further. I still think you should follow the Apache documentation advice and use an * for the names like I described. You may also want to consider restarting your entire server. Sometimes Apache gets a stuck worker process and maybe is not seeing the most recent configuration