It produced this output:
Domain: www.carespanhealth.com
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
2033753c2bcba039c876a87a716dc063.7d91918a9ca94e4e0e85a36513ad7bfa.acme.invalid
from 66.161.32.89:443. Received certificate containing
’carespanhealth.com, www.carespanhealth.com’
My operating system is (include version): CENTOS 7
My web server is (include version): Apache
I can login to a root shell on my machine (yes or no, or I don’t know): Yes
I have a currently active wildcard cert that expires in 28 days. Is this the cause of the error?
Because I have multiple vhosts conf files, I generate the certs then manually add them to my Apache config. I have done this on another server but this server seems to not like me.
I have disabled https on this site both here and in the .htaccess file. Same result. Ideas?
a) From the point of view of all the clients out there on the internet you don’t have a wildcard certificate: just a GoDaddy cert for carespanhealth.com and www.carespanhealth.com. Not *.carespanhealth.com.
b) Do you use some kind of reverse proxy such as a CDN from GoDaddy? Because certbot --apache uses the ‘local’ Apache to try and verify the tls-sni-01 challenge, it can’t be ran on a different server.
I guess you’re right. I only have the www cert. And no. I use a virtual host that I control at the AT&T data center. By godaddy DNS parameters are exactly the same is the ones for my certs that work (leadinar.com). For that site. I have to disable port 443 in my vhosts file. I tried the same on carespanhealth but get the same response. These two sites are on different VMs, but they are configured similarly.
Disabling port 443 shouldn’t be necessary. The way the tls-sni-01 (which is used when using --apache for the authentication part) challenge works is generating a temporary self-signed certificate (with something like your 2033753c2bcba039c876a87a716dc063.7d91918a9ca94e4e0e85a36513ad7bfa.acme.invalid as the common name) and a temporary vhost configuration file pointing to the aforementioned self-signed certificate. Next it reloads your Apache, so the Let’s Encrypt servers can find it.
Problems can arise with the tls-sni-01 challenge when a) DNS points to another server than the server certbot is running on (which isn’t the case you just said) or b) something is wrong/‘messing up’ your Apache. Some users had a non-default configuration of their Apache which didn’t properly ‘pick up’ the Let’s Encrypt temporary configuration file. You could run certbot with the extra -v switch so it outputs more verbose information. Even -vv is possible, but gives you a lot of junk too.
This is getting frustrating. Nothing I do seems to help. I get the same error. The site is currently running with a cert that expires in 14 days. Do I need to disable that first? What kinds of things in the Apache config can cause a problem if that is it? I am stuck.