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:
I ran this command:
/usr/bin/certbot --apache --expand -d louise.ingber.com
It produced this output:
/usr/bin/certbot --apache --expand -d louise.ingber.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for louise.ingber.com
First of all, unfortunately the certificate managing options of Certbot are terrible. Adding --expand to the command line options with only the new hostname does not expand an existing certificate: Certbot wouldn't know what certificate to pick to expand.
To properly expand a certificate, you'd need to, unfortunately, do the following:
Run certbot certificates and find the certificate you want to expand;
Note the "certificate name" from the previous step, let's call that name CERTIFICATE NAME;
Note the list of hostnames after "Domains:" from the first step, lets call those hostnames OLDDOMAINS;
Run certbot --apache --expand --cert-name CERTIFICATENAME -d "OLDDOMAINS" -d NEWDOMAIN
This will make sure you're expanding the correct certificate and you include the previous domains and the new domain. I really wish there was an easier way, but unfortunately, there is none.
As for the actual error: I'm not sure why that's happening. Except for the certificate error, it seems IPv4 and IPv6 are returning the proper site.
Hm, it probably has something to do with the usage of IP addresses for the VirtualHosts.
Could you do the same command (apachectl -t -D DUMP_VHOSTS) but now when Certbot has loaded the challenge?
You can do that by running the Certbot command you'd like to succeed (see my post above about expanding an existing certificate), but now add the option --debug-challenges. That option will pause Certbot when the challenge has been loaded into Apache. When Certbot is paused, please run the apachectl -t -D DUMP_VHOSTS command and show the output again.
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.
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.
Certbot often doesn't play nice when <VirtualHost> sections are using IP addresses instead of a wildcard (*). Do you actually require IP based virtual hosts?
If not, it might be better to combine the two <VirtualHost 173.255.212.226:80> and <VirtualHost [2600:3c01::f03c:91ff:fe93:e6f3]:80> sections into a single <VirtualHost *:80> section. And the same for port 443.
a file would define all the options common to the virtualhosts, ready to be included in each of them.
I would have a single port 80 virtualhost, *:80 and its only job would be to redirect to https on the same domain name. Optionally, you could make it answer acme challenges with a dedicated webroot (only for requests hitting .well-known/acme-challenge using a Location block)
I would have one file for each virtualhost (or one for all of them, it only matters if you want to use a2ensite and a2dissite) with the bare minimum, like:
ServerName
DocumentRoot
Include /etc/apache2/snippets/common_options.conf (this includes the certificate, because yours covers all names. If you get a certificate for each name, then every virtualhost gets its own certificate and key)
curl -Ii6 http://louise.ingber.com/.well-known/acme-challenge/Test_File-1234
HTTP/1.1 302 Found
Date: Fri, 04 Mar 2022 23:09:31 GMT
Server: Apache
Location: https://louise.ingber.com/.well-known/acme-challenge/Test_File-1234
Content-Type: text/html; charset=iso-8859-1
A failed connection:
curl -Ii6 https://louise.ingber.com/.well-known/acme-challenge/Test_File-1234
curl: (51) SSL: no alternative certificate subject name matches target host name 'louise.ingber.com'
Correct "a response" and "the right response" are two very different things.
I suppose the IP based virtual host is largely to blame, but since it is Apache, well... you should already know how I feel about that.
