How to remove persistent server SSL cert (or problem with hostname or cURL)

[harro]

Good day, I have a new server (LXC) based on a newly installed other server. I have great trouble removing all references to the old server hostname (admin settings, hosts file, hostname file, directadmin.conf and options.conf. There is still a reference to the old hostname because I cannot make a (new) Letsencrypt certificate.


# /usr/local/directadmin/scripts/letsencrypt.sh request_single lezard.plie.nl 4096
Setting up certificate for a hostname: lezard.plie.nl
Challenge pre-checks for http://lezard.plie.nl/.well-known/acme-challenge/letsencrypt_1597824098 failed... Command:
/usr/local/bin/curl --connect-timeout 40 -k --silent --resolve lezard.plie.nl:80:5.200.11.122 --resolve lezard.plie.nl:443:5.200.11.122 -I -L -X GET http://lezard.plie.nl/.well-known/acme-challenge/letsencrypt_1597824098
Exiting.


When I check the validity of the certificate that I was able to make yesterday I get the following:

Certificate does not match name lezard.plie.nl

Subject	moustique.plie.nl
Valid from 18/Aug/2020 to 16/Nov/2020
Issuer	Let's Encrypt Authority X3

I think that perhaps there is an issue with cURL? I can also not make backups.

So in short:
- I need to renew the SSL certificates to reflect the correct hostname
- I cannot replace the SSL cert with Letsencrypt due to unclear errors
- I want to delete the old certificate file, hoping that this may trigger a new SSL cert if I start the process.
- I may have a problem with cURL, but other than repeating ./build curl I do not see how to problem-solve


Thank you and kind regards,

Harro

 

[harro]

Looking further on this issue, two further conclusions:

1 - the letsencrypt.sh script cannot seem to write the letsencrypt_[datestamp] file to the well-known directory

when I run
# ./letsencrypt.sh request `hostname` 4096
no new file is created in the /var/www/html/.well-known/acme-challenge/ folder


2 - even when I manually create my own letsencrypt_[datestamp] file, I CANNOT open it with the webbrowser. HOWEVER, if I create the test.txt file in the same well-known folder, I CAN open it with the webbrowser

The files that I have in the folder now are:

# la /var/www/html/.well-known/acme-challenge/
total 12
4 drwx--x--x 2 webapps webapps 4096 Aug 24 22:47 .
4 drwx--x--x 3 webapps webapps 4096 May 3 2016 ..
0 -rw-r--r-- 1 webapps webapps 0 Aug 24 22:29 letsencrypt_1598300909
0 -rw-r--r-- 1 webapps webapps 0 Aug 24 22:29 letsencrypt_1598300975
0 -rw-r--r-- 1 webapps webapps 0 Aug 24 22:47 letsencrypt_1598302200
4 -rw-r--r-- 1 webapps webapps 5 Aug 24 22:23 test.txt


So:
https://hostname.server.com/.well-known/acme-challenge/test.txt --> loads in the webbrowser
https://hostname.server.com/.well-known/acme-challenge/letsencrypt_1598300909 --> does NOT load


Any ideas what may cause this abnormal behaviour?

 

[harro]

The problem lies in using a configured DirectAdmin LXC container as the basis for new servers. I still don't know how to fix it, but I can see that

a) when the letsencrypt script is running, it tries to confirm resolving the hostname with the IP address of the original (former) server hostname (before the LXC container was re-used).

# /usr/local/directadmin/scripts/letsencrypt.sh request_single appa.pakanet.nl 4096
Setting up certificate for a hostname: appa.pakanet.nl
Challenge pre-checks for http://appa.pakanet.nl/.well-known/acme-challenge/letsencrypt_1599421852 failed... Command:
/usr/local/bin/curl --connect-timeout 40 -k --silent --resolve appa.pakanet.nl:80:5.39.184.43 --resolve appa.pakanet.nl:443:5.39.184.43 -I -L -X GET http://appa.pakanet.nl/.well-known/acme-challenge/letsencrypt_1599421852
Exiting.

e.g server A (appa.pakanet.nl) was working fine, until I used that server as a basis for a new server (changed the hostname, ipswap, removed the ssh certificates, checked the options.conf, directadmin.conf for references, etc.). Then when I request a Letsencrypt SSL certificate for the hostname of Server B, Server A suddenly redirects to server B ...

The IP address 5.39.184.43 the letsencrypt uses, as shown in the quote above is NOT the ip address of that server hostname but that of the server B. This used to show the correct IP address but now it is replaced by the IP-address of server B.


So without touching server A, somehow the certificate process on server B causes a change in the redirect behaviour of the original server A (which means Server A is no longer reachable through DA and the SSL cert is invalidated.

Two problems are involved:

1) the admin email address was the same in both servers (I overlooked this when cleaning the old backup as an LXC 'template'), which presumably has a consequence on the Letsencrypt server to mix up the servers/hostnames.

2) somewhere on the server (linked to letsencrypt or another cert file) there is a remnant of the old IP that was not properly updated by the ipswap.sh script.



So the problem boils down to three elements (please help with any thoughts):

1 - How to remove the IP address reference to the old/original server on the new server (which was overlooked by the ipswap.sh script)

2 - How to remove all the (faulty) Letsencrypt data/certificates linked to the hostname, so that I can start again with the correct IP and a new email address for admin

3 - What is a structural solution to this, so that a freshly installed DA LXC container can be used as a 'template'?

 

[harro]

It turned out to be a DNS issue - on the nameservers the server had its own zone file (hostname.domain.com) with different IP addresses than the main zone file for the domain (containing all server hostnames, etc.). After deleting the server hostname zone file, the situation normalised and I was able to make new certificates for the hostname and there was no redirect to another server.