Auto SSL Not Working

Pol33li

Member
Jan 26, 2021
15
3
3
New Mexico
cPanel Access Level
Root Administrator
I setup AutoSSL back in January, but after April 14's checkup, I started getting these errors in the log and now our SSL went down disabling usage of our apps:

WARN Local HTTP DCV error (sub1.domain.tld): The content “<!doctype html><html lang="en"><head><meta charset="utf-8"/><link rel="icon" href="/favicon.ico"/><meta name="viewport" content= …” of the DCV (Domain Control Validation) file, as accessed at “http://sub1.domain.tld/.well-known/pki-validation/_ID_.txt”, did not match the expected value. The domain “sub1.domain.tld” resolved to an IP address “X.X.X.X” that does not exist on this server.
WARN Local HTTP DCV error (sub2.domain.tld): The system failed to fetch the DCV (Domain Control Validation) file at “http://sub2.domain.tld/.well-known/pki-validation/_ID_.txt” because of an error: The system failed to send an HTTP (Hypertext Transfer Protocol) “GET” request to “http://sub2.domain.tld/.well-known/pki-validation/_ID_.txt” because of an error: Cpanel::Exception/(XID trbq93) “sub2.domain.tld.well-known” does not resolve to any IP addresses on the internet.. The domain “sub2.domain.tld” resolved to an IP address “X.X.X.X” that does not exist on this server.
The subdomains are configured on the same server. The X.X.X.X IP is our domain host where a CNAME was setup for the sub1 and sub2 subdomains.

Has anything changed recently that would break the configuration?
 
Last edited by a moderator:

ankeshanand

Well-Known Member
Mar 29, 2021
66
15
8
India
cPanel Access Level
Root Administrator
I setup AutoSSL back in January, but after April 14's checkup, I started getting these errors in the log and now our SSL went down disabling usage of our apps:



The subdomains are configured on the same server. The X.X.X.X IP is our domain host where a CNAME was setup for the sub1 and sub2 subdomains.

Has anything changed recently that would break the configuration?
It seems that AutoSSL is working correctly and You need to check the IP Address of Domain for which you are issuing a SSL. Go to Link and check if your SubDomains forward to the IP address configured with Server.
 
  • Like
Reactions: cPRex

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
4,768
587
273
cPanel Access Level
Root Administrator
@Pol33li - we're happy to move threads to the correct area, so there's no need to make multiples - just let us know!

As far as the AutoSSL system, it has no knowledge of operating systems or containers - it only sees the DNS records. If the DNS doesn't respond properly, it won't be able to issue the certificate for the domain.

With your error, you'll want to make sure the domain does resolve to an IP address on the server where you are running the AutoSSL tool.
 

Pol33li

Member
Jan 26, 2021
15
3
3
New Mexico
cPanel Access Level
Root Administrator
With your error, you'll want to make sure the domain does resolve to an IP address on the server where you are running the AutoSSL tool.
Thanks, I believe we resolved the IP address issue last night through the creation of a config file.

Clarity of the situation: In January, the SSL certificates for two subdomains were successfully installed because the two subdomain directories were acting as normal directories, which allowed the AutoSSL script to write the keys into the default /.well-known/ directories (I didn’t have the containers linked until after the subdomains and SSL were both working).

I then connected the containers. The configuration was "working" until the SSL renewal process began. The certifier then tried to update the keys in the /.well-known/ directory, but due to the container being configured it was now trying to look inside the container for a /.well-known/ directory.

Is there a Docker command or Apache configuration to make the SSL certbot look to the /.well-known/ on the main server and not try and find it inside the container?
 
Last edited:

Pol33li

Member
Jan 26, 2021
15
3
3
New Mexico
cPanel Access Level
Root Administrator
Thank you for the resource.

In the end I "removed" the containers from the subdomains, installed a cert, and then reconnected the containers. Will probably install a 1-2 year cert to nullify the need to repeat this every 90 days.
 
  • Like
Reactions: cPRex