Hostname SSL

[InTheWoods]

There are several different conflicting KB articles on this.

I want to secure the hostname of my server. By default, DA now installs to server-xx-xx-xxx-xx.da.direct instead of the FQDN or IP of the server as it used to.

When trying to secure the actual hostname of the server (Ex: host.myserver.com) the LetsEncrypt certificate shows this:

root@host:~# /usr/local/directadmin/scripts/letsencrypt.sh request host.server.com 4096
Setting up certificate for a hostname: host.server.com
2024/10/22 02:53:19 [INFO] [server-xx-xxx-xx-xx.da.direct] acme: Obtaining SAN certificate
2024/10/22 02:53:20 [INFO] [server-xx-xxx-xx-xx.da.direct] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/xxxxxxxx
2024/10/22 02:53:20 [INFO] [server-xx-xxx-xx-xx.da.direct] acme: authorization already valid; skipping challenge
2024/10/22 02:53:20 [INFO] [server-xx-xxx-xx-xx.da.direct] acme: Validations succeeded; requesting certificates
2024/10/22 02:53:23 [INFO] [server-xx-xxx-xx-xx.da.direct] Server responded with a certificate for the preferred certificate chains "ISRG Root X1".
Certificate for server-xx-xxx-xx-xx.da.direct has been created successfully!
DirectAdmin certificate has been setup.
Setting up cert for Exim...
Setting up cert for Dovecot...
Setting up cert for nginx...

As you see, it just uses the DA hostname instead of the ACTUAL hostname despite me specifying the actual hostname.

The actual hostname is set in the admin panel settings as well, so not sure why the server-IP-address.da.direct is even being used anywhere.

This used to be a simple and straight forward process.

hostname/evo/admin/ssl doesn't help, nothing shown or able to change here.

hostname/evo/admin/server-tls, nothing here to change. Obviously shows a Not Trusted certificate since it is for the DA default hostname (I really wish they'd remove this 'feature' and stick with the IP of the server or FQDN of the server instead at install) but I can't change it. I've tried different things in the ACME settings and Change Certificate settings and nothing works.

What is the proper way to now complete this task?

I want the hostname of my server to be protected by LetsEncrypt. No self-signed cert. No forcing the DA default hostname somewhere. I'd be happy if I never have to see the *.da.direct hostname anywhere ever again, haha.

 

[Active8]

W

Thread '[Solved] SSL and hostname'

Nov 8, 2022

Hello!
I try to setup Let's encrypt for my server hostname (myserver.domain.com) but every time, the request is made for server-XXX-XX-XXX-XX.da.direct and the SSL for *.da.direct is setup as my hostname certificate

I have setup the hostname correctly on the server but the issue remain (in the control panel and with hostname.sh script)...

root@XXXXXXXXXXX:/usr/local/directadmin/scripts# ./letsencrypt.sh request myserver.domain.com 4096
Setting up certificate for a hostname: myserver.domain.com
2022/11/08 22:35:02 [INFO] [server-XXX-XX-XXX-XX.da.direct] acme: Obtaining SAN certificate...

• webaltern
• Replies: 2
• Forum: System-Level Technical Discussion

 

[Richard G]

As you see, it just uses the DA hostname instead of the ACTUAL hostname despite me specifying the actual hostname.

It's a known issue.

Check this article which also explains how to get rid of the automatic hostname definately.

Thread '[How-To] Create or change your server's hostname in Directadmin'

Mar 21, 2024

This is a guide on how to create a correct FQDN hostname on a server or VPS.
I created this newly here in this section, for easier reference and it's also easier to find.

There is also another method, but the method described here is a method which is also still very usable.

Before you install Directadmin you can already take care the correct hostname is used bij Directadmin.

The domain mydomain.com is used her as example and 192.168.0.1 as example server ip. Ofcourse replace all examples with the domain or hostname your are using. So don't use 192.168.0.1 in the real situation, same...

• Richard G
• Replies: 11
• Forum: How-To Guides

• 

 

[InTheWoods]

It's crazy how every - single - time I deploy a new DA server I need to come back to this post to figure out how in the heck to get the hostname SSL to work properly.

How does DirectAdmin not just do this automatically?

You generate some publicly unsuable hostname upon installation now. It's useless and no one will use it in production.

When the hostname of the server is changed in Dashboard > Administrator Settings > Server Settings, since this specifically requires a FQDN that resolves to the main IP of the server, wouldn't it be wise to then also just create the SSL for that hostname?

I like DirectAdmin beccause it's mostly hassle free once setup, but you guys make the setting up part much more of a headache than it needs to be.

In the admin panel two SSL options exist (Admin SSL and Server TLS Certificate), neither of which do anything at all. According to the Server TLS Certificate page, after manually adding the hostname on the ACME Settings page, everything is "valid" yet still not working in the browser.

So this forces users to then do the whole CLI BS of removing old certs manually and reissuing manually, via CLI. Something that could all be done automatically or from the web UI.

Rant over, just had to come back to this thread to figure out how to get this new deployment to work since it never does out of the box and I have to spend time reading documentation and old forum threads for a very basic thing like a valid SSL for the server's hostname/URL that users will access to login.

 

[Richard G]

You generate some publicly unsuable hostname upon installation now. It's useless and no one will use it in production.

I also found this a bad idea. But DA found it a good idea as this way people were intantly able to visit the panel via SSL without the need to having knowledge about hostnames.
There are people using it this way.

But we have had way more people who did not benefit from doing up a bit of knowledge up front, resulting in mail issues with mail send via de hostname like from php scripts for example.
Before this was changed in DA, then the hostname was -always- created via a seperate DNS entry same way it's done via my manual. And then these issues did not arise. Except only people with less knowledge had to change the name.
After it was changed to the ip.da.direct hostname, issues start to arise as also no seperate hostname entry was made anymore by DA by default and also (probably for that reason) the /etc/virtual/hostname bug had arisen.

In the panel the things should work indeed, but as long as at least the hostname is not changed in the correct way after changing in the panel (see bug I mentioned in my manual), that won't work and it's known for years.

At least I'm glad I see my manual still helps people.

 

[Zhenmue]

we have like 4 tickets related to this same issue.

and we see this very same issue very few months with a new DA Server, but now instead of opening a new ticket, we just check the latest, were the commands and procedures are written to fix this. we even have to move some files according to DA Support. anyway... an issue created by DA itself for every admin using their software.

 

[DrWizzle]

Whenever I setup a server, I now simply spin up the server, update it and set the DA_HOSTNAME= variable in bash along with the admin name, email and 2 Nameservers. Set a FQDN DNS record for the hostname and then install DA. I don't get any random xx.xx.xx.xx.da.direct hostname to change, the TLS sets up automatically and within seconds I get the link to login to the server with TLS enabled. I found it a bit more cumbersome to install years ago, but now it just seems quite streamlined, for me at least.

 

[Richard G]

Set a FQDN DNS record for the hostname and then install DA.

Where do you set an FQDN DNS record if DA is not installed yet? In the registrar DNS?

And this is the issue. Setting a DNS hostname record should -also- be done by DA automatically (in DA DNS) on installation as they did in the older days. Then the problem would be not occur.
I've used the same method and running to the same issue, hostname is set correctly during installation, so no xx.xxx.xx.da.direct hostname but my own hostname and TLS record (as soon as DNS is pointing to it).
But the seperate DNS record is not or created and the hostname entry is not created in /etc/virtual causing hostname mails to fail.

 

[DrWizzle]

Where do you set an FQDN DNS record if DA is not installed yet? In the registrar DNS?

And this is the issue. Setting a DNS hostname record should -also- be done by DA automatically (in DA DNS) on installation as they did in the older days. Then the problem would be not occur.
I've used the same method and running to the same issue, hostname is set correctly during installation, so no xx.xxx.xx.da.direct hostname but my own hostname and TLS record (as soon as DNS is pointing to it).
But the seperate DNS record is not or created and the hostname entry is not created in /etc/virtual causing hostname mails to fail.

I run my own set of DNS Nameservers. I've got 3 servers scattered over Europe all running Multiserver on simply as DNS servers so they are all linked.

All my servers hostnames are a subdomain of one main domain I own. So in short, i'll pop along to the master DNS server, add a FQDN A record to the domains DNS and leave it 30 mins or so. Once i've spun up the VPS or Metal server, depending on what i'm up to, installed the OS, updated it and set the DA_HOSTNAME variables, the A record has propogated enough to get picked up by ACME when it's time to issue the TLS record.

If anyone's setting up a DA server without a FQDN as I have done in the past, it defaults to xx.x.xx.xxx.da.direct to get a TLS cert for people to log into straight away as has been said before here in this thread as it's looking for something to resolve to. If you set the hostname, and TLS fails, you either have to login with the IP or hostname over port 80 and manually set it all up.

If you don't have any DNS for your domain yet, It is possible to glue the IP at your registrar and run your own DNS on the same server, but you'd again, have to setup the TLS manually as there wouldn't be a resolveable FQDN for the hostname until the DNS server was up and running.

1 last tip i've found over the years is if you set the DA_HOSTNAME variable, you invariably don't get the xxxx.da.direct hostname setup. I know many run their servers happily with that hostname setup as it suits them, or they don't know any different, but it just saves having to rename server and mess about more if your hostname is set from scratch and just have to manually set the TLS.

 

[Richard G]

All my servers hostnames are a subdomain of one main domain I own.

Hostnames are never called subdomains. They look like subdomains but never called that way. If you create real subdomains for your hostname, that might be possible and working but would be an odd way to work with hostnames. They should normally not be subdomains.
So be aware to use correct terms to not confuse others.

If it's only an A record (so similar to subdomain), yes that's one way of doing it.

If you only use an A record for your hostname, like server.example.com in the domain example.com don't you ever have issues with e-mail send via the hostname like php can do?
Also the downside is that you can't use strict SPF records for example.com for that reason.
Or you have to create a seperate SPF record for your hostname.

I rather like the older method from my manual, easier, less work to achieve some things.

But that's a choice everyone can make for themselves.