Solved Hostname SSL Was Skipped Due To Unreachable /.well-known

[hostmost]

Hi there!

I've set up a second server with DA on AlmaLinux 9. Everything has been installed successfully. I was able to connect via some strange domain that I hadn't seen before. Something like xx-xx-xx-xx.da.direct (it's proxied by DA servers, I believe).

Once I set the real Hostname to the DA platform, it's changed, but SSL not working any longer. The VM itself has the correct server name as well.

On the first server which I've been running for over 2 years now all the A records are pointing correctly to the second machine as well.

I tried researching the DA forum to find similar problems. I've found 1 thread with suggestions to delete all the .pem and .cert files in /usr/local/directadmin/
After removing those files, the DA is not starting any longer. I tried creating them all empty, same thing. Only after returning them back, it start up.

The DA documentation regarding Letsencrypt is not helping. I've tried it all, and each time I'm getting this error:

[root@server2 myuser_com]# /usr/local/directadmin/scripts/./letsencrypt.sh request_single server2.myhostname.com 4096
Setting up certificate for a hostname: server2.myhostname.com
server2.myhostname.com was skipped due to unreachable http://server2.myhostname.com/.well-known/acme-challenge/ file.

I tried renewing, requesting, deleting, renewing, or requesting again, but nothing worked.

However, If I'm following the link xx-xx-xx-xx.da.direct (the SSL is working), however, this is not my actual hostname.

Please, help!

 

[Richard G]

If I'm following the link xx-xx-xx-xx.da.direct

This is the ip address and then .da.direct as last. They did it like this to ensure that ssl would be working after installation.

It's a good thing that you changed the hostname, however, where and how did you exactly do that?

Change hostname in directadmin.
Then check the /etc/hosts file and the /etc/hostname file if the full fqdn hostname is in there.

Once that is done, maybe this is what is missing (seems a bug in DA).
Create a seperate DNS entry for your hostname via the DNS Administration in the admin section.
You have to put in there your hostname, your ip address and the nameservers.

Once that is done doublecheck that your fqdn hostname is present in:
/etc/virtual -> as directory
/etc/virtual/domains (this is a file).
it should NOT be present in the /etc/virtual/domainowners file.

If that is all correct, just to be sure, restart your network or reboot the server.
Verify that both hostname and hostname -f will give you the full server2.myhostname.com (your hostname) as output.

It the out put is correct, then try to request a certificate for your hostname again. Should be working now.

 

[hostmost]

This is the ip address and then .da.direct as last. They did it like this to ensure that ssl would be working after installation.

It's a good thing that you changed the hostname, however, where and how did you exactly do that?

Change hostname in directadmin.
Then check the /etc/hosts file and the /etc/hostname file if the full fqdn hostname is in there.

Once that is done, maybe this is what is missing (seems a bug in DA).
Create a seperate DNS entry for your hostname via the DNS Administration in the admin section.
You have to put in there your hostname, your ip address and the nameservers.

Once that is done doublecheck that your fqdn hostname is present in:
/etc/virtual -> as directory
/etc/virtual/domains (this is a file).
it should NOT be present in the /etc/virtual/domainowners file.

If that is all correct, just to be sure, restart your network or reboot the server.
Verify that both hostname and hostname -f will give you the full server2.myhostname.com (your hostname) as output.

It the out put is correct, then try to request a certificate for your hostname again. Should be working now.

Thank you for your reply. I did exactly as described, and this is what I'm getting.

If I'm using this script:

/usr/local/directadmin/scripts/./letsencrypt.sh request 'server1.myhostname.com -f' 4096

I'm getting this output:

Setting up certificate for a hostname: server1.myhostname.com
2023/08/29 11:26:42 [INFO] [server-xx-xxx-xxx-xxx.da.direct] acme: Obtaining SAN certificate
2023/08/29 11:26:42 [INFO] server-xx-xxx-xxx-xxx.da.direct AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/258895156196
2023/08/29 11:26:42 [INFO] [server-xx-xxx-xxx-xxx.da.direct] acme: authorization already valid; skipping challenge
2023/08/29 11:26:42 [INFO] [server-xx-xxx-xxx-xxx.da.direct] acme: Validations succeeded; requesting certificates
2023/08/29 11:26:45 [INFO] [server-xx-xxx-xxx-xxx.da.direct] Server responded with a certificate for the preferred certificate chains "ISRG Root X1".
Certificate for server-xx-xxx-xxx-xxx.da.direct has been created successfully!
DirectAdmin certificate has been setup.
Setting up cert for Exim...
2023/08/29 11:26:45 info executing task task=action=exim&value=restart
2023/08/29 11:26:46 info executing task task=action=dovecot&value=restart
Setting up cert for WWW server...
2023/08/29 11:28:17 info executing task task=action=httpd&affect_php_fpm=no&value=graceful
Setting up cert for FTP server...
2023/08/29 11:28:17 info executing task task=action=proftpd&value=restart
2023/08/29 11:28:18 info executing task task=action=directadmin&value=restart

I even tried deleting the server1.myhostname.com from the DNS Administration and created it once again, with no changes.

Also tried running this command:

/usr/local/directadmin/scripts/./letsencrypt.sh request_single 'server1.myhostname.com -f' 4096

Here is the output:

+short: No such file or directory
/usr/bin/dig: couldn't open specified batch file
+short: No such file or directory
/usr/bin/dig: couldn't open specified batch file
-f was skipped due to unreachable http://-f/.well-known/acme-challenge/ file.
No domains pointing to this server to generate the certificate for.

Please, advice.

Thank you!

 

[Richard G]

Also tried running this command:

That command is incorrect. It's either 'hostname -f' or the full hostname without quotes.

Try like this:
/usr/local/directadmin/scripts/./letsencrypt.sh request_single server1.myhostname.com 4096

By the way, I have seen some odd things happening lately on some servers. Doublecheck that server1.myhostname.com is present as directory in the /etc/virtual directory before issuing the above command.

 

[hostmost]

That command is incorrect. It's either 'hostname -f' or the full hostname without quotes.

Try like this:
/usr/local/directadmin/scripts/./letsencrypt.sh request_single server1.myhostname.com 4096

By the way, I have seen some odd things happening lately on some servers. Doublecheck that server1.myhostname.com is present as directory in the /etc/virtual directory before issuing the above command.

I verified the existence of server1.myhostname.com in /etc/vitrual (and it's empty, as it should) before running the command.

Here is the output:

Setting up certificate for a hostname: server1.myhostname.com
server1.webhostmost.com was skipped due to unreachable http://server1.myhostname.com/.well-known/acme-challenge/ file.
No domains pointing to this server to generate the certificate for.

 

[Richard G]

Here is the output:

That is odd. So it does exist in DNS administration right? You added it as seperate domain, correct?
Can you check the /etc/virtual/domains file if server1.myhostname.com is present in there too?
It should -not- be in the /etc/virtual/domainowners file.

Are you using external DNS? If yes, did you add the hostname record there too? Can it be resolved if you try with the dig command from another server?
If you want you can give me the hostname per pm then I can check, but can take an hour because I will get visitors within 10 minutes.

But I guess somewhere some DNS entry is missing because it's not resolving or not resolving yet.

 

[hostmost]

That is odd. So it does exist in DNS administration right? You added it as seperate domain, correct?
Can you check the /etc/virtual/domains file if server1.myhostname.com is present in there too?
It should -not- be in the /etc/virtual/domainowners file.

Are you using external DNS? If yes, did you add the hostname record there too? Can it be resolved if you try with the dig command from another server?
If you want you can give me the hostname per pm then I can check, but can take an hour because I will get visitors within 10 minutes.

But I guess somewhere some DNS entry is missing because it's not resolving or not resolving yet.

Yes, it does exist in DNS Administration. Yes, I added it as a separate DNS record.
Yes, it does present in /etc/virtual/domains
It is NOT present in /etc/virtual/domainowners file.

I'm running 2 machines with with Gcloud, and I have Cloud DNS with Gcloud as well, however my 2 servers are managing all the DNSes. I have Server 1 and Server 2. Both manage DNS records as Master & Slave.

I tried resolving it from my local machine (dig server1.yhostname.com) and instantly got results that seem to be working because it shows my server IP.

I'm going to DM you now as well.

Thank you!

 

[gate2vn]

Check if you have IPv6 in the domain's DNS records. Yesterday, I had the same issue with a domain which was configured for both IPv4 and IPv6. Needed to delete IPv6 DNS records, then could setup SSL.

 

[Richard G]

Hmmz odd... I didn't have any issue with the hostname SSL with both ipv4 and ipv6.

In this case it seems nameservers are not propagated properly yet, or at least when we DM each other.

 

[hostmost]

Hmmz odd... I didn't have any issue with the hostname SSL with both ipv4 and ipv6.

In this case it seems nameservers are not propagated properly yet, or at least when we DM each other.

Yes, you are correct. You can use a Single or Dual Stack Network. It does not matter. What matters for LetsEncrypt is your hostname that must propagate everywhere, and (dnschecker.org) is an excellent tool for checking.

I've verified IPv6 addresses on both Nameserver's DNS from DirectAdmin DNS Administration and found 1 record missing. Added missing IPv6 record, refreshed existing DNS records for each hostname by opening the record and saving it again, and got all the records propagated correctly across all the regions.

After that, LetsEncrypt worked instantly.