Remove FQDN da.direct installed by default

stefanos

New member
Joined
Feb 7, 2024
Messages
3
Hy guys,
i can't figure out how to remove hostname set by default from DA.
Tried to follow a lot of posts here, like this: https://forum.directadmin.com/threads/sll-for-hostname-still-getting-old-hostname.69119/#post-365800

I checked all files involved after that, and all seems to be fine, but when i try to use Let'encrypt tool i obtain this:

[root@server log]# cd /usr/local/directadmin/scripts
[root@server scripts]# ./letsencrypt.sh request_single $(hostname -f) 4096
Setting up certificate for a hostname: server.a******a.com
2024/02/07 16:28:34 [INFO] [server-xx-xx-xx-xx.da.direct] acme: Obtaining SAN certificate
2024/02/07 16:28:35 [INFO] [server-xx-xx-xx-xx.da.direct] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/310475144577
2024/02/07 16:28:35 [INFO] [server-xx-xx-xx-xx.da.direct] acme: authorization already valid; skipping challenge
2024/02/07 16:28:35 [INFO] [server-xx-xx-xx-xx.da.direct] acme: Validations succeeded; requesting certificates
2024/02/07 16:28:38 [INFO] [server-xx-xx-xx-xx.da.direct] Server responded with a certificate for the preferred certificate chains "ISRG Root X1".
Certificate for server-xx-xx-xx-xx.da.direct has been created successfully!
DirectAdmin certificate has been setup.
Setting up cert for Exim...
2024/02/07 16:28:38 info executing task task=action=exim&value=restart
2024/02/07 16:28:39 info executing task task=action=dovecot&value=restart
Setting up cert for WWW server...
2024/02/07 16:28:39 info executing task task=action=httpd&affect_php_fpm=no&value=reload
Setting up cert for FTP server...
2024/02/07 16:28:40 info executing task task=action=pure-ftpd&value=restart
2024/02/07 16:28:40 info executing task task=action=directadmin&value=restart
[root@server scripts]#

From another server, it seems the SOA of that fqdn is external:
[root@srv ~]# dig SOA server-xx-xx-xx-xx.da.direct +short
ns1.da.direct. martynas.directadmin.dev. 1 10800 3600 604800 3600
[root@srv ~]#

DA version: DirectAdmin v.1.659

What else can i try to do?
Thanks in advance
 
Hello,

Remove the following files (it is OK if any is missing):

  • /usr/local/directadmin/conf/ca.csr
  • /usr/local/directadmin/conf/ca.san_config
  • /usr/local/directadmin/conf/cacert.pem
  • /usr/local/directadmin/conf/cacert.pem.combined
  • /usr/local/directadmin/conf/cacert.pem.creation_time
  • /usr/local/directadmin/conf/cakey.pem
  • /usr/local/directadmin/conf/carootcert.pem
  • /usr/local/directadmin/conf/letsencrypt.key
  • /usr/local/directadmin/conf/letsencrypt.key.json
and re-generate the certificate
 
I checked all files involved after that, and all seems to be fine, but when i try to use Let'encrypt tool i obtain this:
With somebody else, it was caused because the ip.da.direct hostname was still present in the /etc/hosts file. Maybe also in the /etc/hostname file.

When you change it in /etc/hosts and restart your network or reboot the server/vps then it should be fixed also.
However, you can also remove the files mentioned above next to adjusting the hostfile.
 
However, you can also remove the files mentioned above next to adjusting the hostfile.

Kindly do not mislead others, Richard. You might try the things:

Code:
/usr/local/directadmin/scripts/hostname.sh anything-is-here.example.net
/usr/local/directadmin/scripts/letsencrypt.sh request $(hostname -f) 4096

and you might see DirectAdmin re-creates a SSL certificate for your original hostname, but not anything-is-here.example.net
 
Kindly do not mislead others, Richard. You might try the things:
I'm not misleading anybody @zEitEr, just saying what I experience on the forums.
Check this thread for example:
there was also another thread with same thing, change /etc/hosts file, but can't find it that quick anymore.

You might try the things:
If they were called correctly by the hostname change in DA itself, then the first script should not be necessary to call manually. So I'm not misleading anything.

The second line for the hostname is already stated in my manual.
 
/usr/local/directadmin/scripts/hostname.sh anything-is-here.example.net
/usr/local/directadmin/scripts/letsencrypt.sh request $(hostname -f) 4096
So you mean DA would only look at the existing certificates for the old holsfile? If yes then I wonder why LE would create a certificate for the new hostname without the certs being removed.
Bit of confusing to me as it's no question of renewing existing certificates, but the request_single will request new certificates.
And I myself have also not removed existing certs and still got the correct certificates when having this issue some time ago. Just changing the hostname in /etc/hosts and /etc/hostname was enough as hostname -f command will give the correct hostname new then too. No difference als the hostname -f called with the LE request.

However I will add the remove option in my manual just for completeness.
 
Remove the following files (it is OK if any is missing):

  • /usr/local/directadmin/conf/ca.csr
  • /usr/local/directadmin/conf/ca.san_config
  • /usr/local/directadmin/conf/cacert.pem
  • /usr/local/directadmin/conf/cacert.pem.combined
  • /usr/local/directadmin/conf/cacert.pem.creation_time
  • /usr/local/directadmin/conf/cakey.pem
  • /usr/local/directadmin/conf/carootcert.pem
  • /usr/local/directadmin/conf/letsencrypt.key
  • /usr/local/directadmin/conf/letsencrypt.key.json

Thank you! It worked like a charm
And many thanks also to you, Richard G, i learned a lot reading your posts.

From another server, it seems the SOA of that fqdn is external:
[root@srv ~]# dig SOA server-xx-xx-xx-xx.da.direct +short
ns1.da.direct. martynas.directadmin.dev. 1 10800 3600 604800 3600
[root@srv ~]#

Untitled.png

Old FQDN is still resolving my vps ip address. Is that normal?
 
Old FQDN is still resolving my vps ip address. Is that normal?
Probably yes.
If you changed your hostname and you have a hostname A record somewhere, it can take a bit of time before it's synched between DNS systems around the world.
This can also cause LE to request the old hostname if the new one does not resolve yet everywhere.
Best is after hostname change, wait until it resolves, then make the new LE request, just to be sure.

Normally the new hostname should resolve after an hour or 2 max.

And yes, the da.direct domain is owned by DA, so ofcourse the nameservers and SOA of the da.direct domain is external, that is correct.
 
@Richard G
I changed hostname about 4 or 5 hours ago, and now DNS systems around the world are resolving old hostname FQDN (da.direct) and new hostname on the same vps ip.

Yes, I have a zone named "server.domain.com" (with server ip record A configured)
 
@Richard G

I did not read the guide you are referring to, Richard. That's great you wrote the guide. Thank you for t it. I was referring to the named need to modify the file /etc/hosts manually and following reboot. The both are not required on modern systems when you use system hostnamectl or directadmin hostname.sh scripts. This is the only part I was referring to.

So I'd rather use a directadmin script for changing a hostname:

Code:
/usr/local/directadmin/scripts/hostname.sh new.hostname.example

and then control output with hostnamectl. In most cases the DA script /usr/local/directadmin/scripts/hostname.sh works fine.

As of the files and the need to remove the files, here is a code snippet from /usr/local/directadmin/scripts/letsencrypt.sh

Bash:
if [ -s "${CERT}" ] && [ "$1" = "renew" ]; then
    if [ -s "${CERT}" ]; then
        DOMAIN=$(${OPENSSL} x509 -text -noout -in "${CERT}" | grep -m1 'Subject Alternative Name:' -A1 | grep 'DNS:' | perl -p0 -e 's|DNS:||g' | tr -d ' ')
    fi
elif [ "$1" = "request" ] && ! echo "${DOMAIN}" | grep -m1 -q ","; then
    if [ -s "${CSR_CF_FILE}" ] && grep -m1 -q 'DNS:' "${CSR_CF_FILE}"; then
        DOMAIN=$(grep '^subjectAltName=' "${CSR_CF_FILE}" | cut -d= -f2 | grep 'DNS:' | perl -p0 -e 's|DNS:||g' | tr -d ' ')
    elif [ -s "${CERT}" ] && ${OPENSSL} x509 -text -noout -in "${CERT}" | grep -m1 -q 'Subject Alternative Name:' >/dev/null 2>&1; then
        DOMAIN=$(${OPENSSL} x509 -text -noout -in "${CERT}" | grep -m1 'Subject Alternative Name:' -A1 | grep 'DNS:' | perl -p0 -e 's|DNS:||g' | tr -d ' ')
    elif [ "${HOSTNAME}" -eq 0 ] && ! ${CHILD_DOMAIN}; then
        if ! echo "${DOMAIN}" | grep -q "^www\."; then
            #We have a domain without www., add www domain to to SAN too
            DOMAIN="${DOMAIN},www.${DOMAIN}"
        else
            #We have a domain with www., drop www and add it to SAN too
            DOMAIN2=$(echo "${DOMAIN}" | perl -p0 -e 's#^www.##')
            DOMAIN="${DOMAIN2},www.${DOMAIN2}"
        fi
    fi
elif [ "$1" = "request_full" ]; then

Where a DOMAIN is taken from CERT and CSR files for "renew" and "request" actions. Though the request "request_single" /usr/local/directadmin/scripts/letsencrypt.sh request_single $(hostname -f) 4096 can be used without prior removal of the mentioned files. Thanks for pointing this to me.

No offence about the guide at all.
 
Hmmz.. that's odd. Nameservers resolve within 4-24 hours normally. But hostnames go much quicker because DNS is already in place.
I presume you also have sent your PTR/rDNS record set correctly?
You can give me the hostname if you want via PM then I will have a look for you if I can find out why it takes that long.

This is the only part I was referring to.
Ah oke that wasn't clear to me, that makes a lot more sense then. I just wrote you a pm by the way. :)
I know the reboot is not required, but network restart often is at least if I'm correct. Indeed when you use commandline like we people normally do, that is not a big issue.
The hostnamectl command is also in my manual. But most people only use the GUI, change hostname there and then think everything is ready. Which unfortunately is not always the case. Odd that the hostname change in the GUI does not change it in the /etc/hosts file.

Thanks for pointing this to me.
No problem, better safe than sorry and thank you for looking this up because just as well I've could also have been wrong ofcourse.
And naturally feel free to comment or give improvements if you see any in my manual, always very appreciated.
 
Hello,

Remove the following files (it is OK if any is missing):

  • /usr/local/directadmin/conf/ca.csr
  • /usr/local/directadmin/conf/ca.san_config
  • /usr/local/directadmin/conf/cacert.pem
  • /usr/local/directadmin/conf/cacert.pem.combined
  • /usr/local/directadmin/conf/cacert.pem.creation_time
  • /usr/local/directadmin/conf/cakey.pem
  • /usr/local/directadmin/conf/carootcert.pem
  • /usr/local/directadmin/conf/letsencrypt.key
  • /usr/local/directadmin/conf/letsencrypt.key.json
and re-generate the certificate
Excellent advice. Been wrestling with this problem since changing server name. You solved it. Thank you.
 
I guess this can be marked as a bug/issue, when doing a few new installs for new servers and setting the hostname after it still uses the old da.direct hostname with the SSL request, obviously the steps mentioned here fixed it but it is utterly frustrating.
 
when doing a few new installs for new servers and setting the hostname after it still uses the old da.direct hostname with the SSL request,
I never had that issue. So it might be depending on if you are creating a seperate DNS zone in DNS administration or not.
If you use an A record in your domain for your server's hostname, then the hostname certificates will not be overwritten.

When using a seperate DNS zone entry (and using own local nameservers) then the hostname certificates will get overwritten. At least until now on changing the hostname and using my own nameservers (zo servers hostname is a real seperate zone), I didn't encounter this issue ever.

But at least you can always use @zEitEr's solution to fix it. In any case if you only use an A record for the hostname you need this.

But again... best is to setup the hostname correctly before installing Directadmin.
 
Back
Top