DirectAdmin 1.706

I've been testing 1.706 using the alpha channel to fix incorrect cipher suites (ticket #71601). That was indeed fixed, but it's missing from the changelog. It removes old ciphers that shouldn't be loading anymore and it has effect on a domain's score on https://internet.nl for example.

Because I couldn't find much documentation and it's now missing from the changelog, I would like to ask (again, now publicly) to add it to the changelog and improve the documentation.

The ACME management for SSL is nice and I've used it for a few domains already. When do you plan to enable it for all domains? If not how can we enable it ourselves for all domains (new and existing)?
 
Where is the csf changelog to be found again?

The ChangeLog can be found in /etc/csf/changelog.txt or in https://files.directadmin.com/services/csf-15.08.tar.gz:

Code:
15.08 - Removed csget update script. 
            Removed Upgrade section from the plugin GUI

Meanwhile https://github.com/poralix/da-csf/commit/810017b0fe6bb09d19c5f848ba156beb51afe284 :

Code:
        modified:   ConfigServer/DisplayUI.pm
        modified:   changelog.txt
        modified:   install.cpanel.sh
        modified:   install.cwp.sh
        modified:   install.cyberpanel.sh
        modified:   install.directadmin.sh
        modified:   install.generic.sh
        modified:   install.interworx.sh
        modified:   install.vesta.sh
        modified:   version.txt
 
Yes it does:
1783952792741.png
 
The warning:

The ACME system is disabled. Please enable it to manage TLS certificates automatically.

seems a bit confusing.

2026-07-14_173710_poralix.png

Can we have it rephrased to something less ambiguous please. For now it makes me and probably other users think a domain is not protected by a certificate and/or an existing one won't be renewed.

And another thing. The commonly used command:

Bash:
/usr/local/directadmin/scripts/letsencrypt.sh request domain.com

does not issue a new certificate as well as the command
Code:
letsencrypt.sh renew domain.com
does not renew an existing one. Even if I change the key-type in CLI. Getting this:

Bash:
2026/07/14 18:07:23  info executing task            task=action=rewrite&domain=poralix.example.net&value=letsencrypt
2026/07/14 18:07:23 debug flushing unbound dns zone acme-mode=domain domain=poralix.example.net hostname=poralix.example.net output=ok removed 3 rrsets, 2 messages and 0 key entries
 user=myuser zone=poralix.example.net
2026/07/14 18:07:24 debug domain should be able to solve DNS challenge acme-mode=domain domain=poralix.example.net hostname=poralix.example.net reason=ns_record_match user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=www.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=mail.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=ftp.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=pop.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=smtp.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=webmail.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24  info finished task             duration=484.06929ms task=action=rewrite&domain=poralix.example.net&value=letsencrypt

How can we request/renew certificates in a console?

The only command is working is

Code:
/usr/local/directadmin/scripts/letsencrypt.sh server_cert [<domain>]

Thank you
 
The warning:



seems a bit confusing.

View attachment 9804
Can we have it rephrased to something less ambiguous please. For now it makes me and probably other users think a domain is not protected by a certificate and/or an existing one won't be renewed.

And another thing. The commonly used command:

Bash:
/usr/local/directadmin/scripts/letsencrypt.sh request domain.com

does not issue a new certificate as well as the command
Code:
letsencrypt.sh renew domain.com
does not renew an existing one. Even if I change the key-type in CLI. Getting this:

Bash:
2026/07/14 18:07:23  info executing task            task=action=rewrite&domain=poralix.example.net&value=letsencrypt
2026/07/14 18:07:23 debug flushing unbound dns zone acme-mode=domain domain=poralix.example.net hostname=poralix.example.net output=ok removed 3 rrsets, 2 messages and 0 key entries
 user=myuser zone=poralix.example.net
2026/07/14 18:07:24 debug domain should be able to solve DNS challenge acme-mode=domain domain=poralix.example.net hostname=poralix.example.net reason=ns_record_match user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=www.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=mail.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=ftp.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=pop.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=smtp.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24 debug DNS name skipped because it is already covered by a valid certificate acme-mode=domain dnsName=webmail.poralix.example.net domain=poralix.example.net user=myuser
2026/07/14 18:07:24  info finished task             duration=484.06929ms task=action=rewrite&domain=poralix.example.net&value=letsencrypt

How can we request/renew certificates in a console?

The only command is working is

Code:
/usr/local/directadmin/scripts/letsencrypt.sh server_cert [<domain>]

Thank you
The "ACME system" refers to the updated automatic TLS certificate system.
Legacy auto-renewal is still functional, and can be seen in the certificate list by the green "Auto-renew" text, despite the ACME system being disabled. Note that legacy auto-renewal will eventually be deprecated and removed with future DA releases.

The letsencrypt.sh script has been updated to enable the ACME system for a domain. For example, running the following:
Bash:
letsencrypt.sh request domain.com
# or
letsencrypt.sh renew domain.com # behaves identically to request
enables the ACME system for the domain and ensures domain.com is covered by a TLS certificate and is automatically renewed in the future whenever needed. If a valid certificate already exists, nothing is done (even if the key type differs, though this may change in future DA releases).
 
The "ACME system" refers to the updated automatic TLS certificate system.
Legacy auto-renewal is still functional, and can be seen in the certificate list by the green "Auto-renew" text, despite the ACME system being disabled. Note that legacy auto-renewal will eventually be deprecated and removed with future DA releases.

Thank you for your efforts and clarification. It is not me who you would need to teach. It is a feedback from regular users who does not know anything about directadmin help pages and forums. And they got confused with the warning. Hence I posted it here.

The letsencrypt.sh script has been updated to enable the ACME system for a domain.

I personally don't like the behaviour of the new script. I understand I'm not the decision maker here as well as no way an influencer. You just removed any way to control certificates creation in favour of a fully automated process. The things are now just "take the things as how they are". Why? What benefits will we get from it? I don't see any as of yet
 
I don't like this new changed... Just keep old letsencrypt.sh working same as before and introduce new thing like "letsencrypt.sh --modern ...",

no one can keep learning that's already should work but need to re-update his document in later again and again.
 
Thanks for the feedback.

@zEitEr, the message on the Certificates pages is to make all users aware of the new ACME system and to encourage them to opt in to it. The interface should be intuitive enough for the users to discover the way to enable the new ACME system.

You are right about the message during the transition period (when both old and new ACME systems are in place). In the long run (when the new ACME system is used by everyone and the old ACME system is removed) the message is accurate.

@Ohm J, @zEitEr, the letsencrypt.sh script is removed (replaced with a call to the new system) to allow us to extend the ACME functionality. The letsencrypt.sh script could NOT:
  • handle custom ACME providers (using ACME protocol for paid certificates).
  • perform early checks for DNS challenge viability.
  • support the new DNS-PERSIST challenge type.
  • compatibility with lego v5 (it has breaking changes for CLI perameters, and we must handle lego version auto-detection).
  • capture the lego execution logs and expose them in the web UI.
We had to move the letsencrypt.sh code from bash to the main directadmin service to be able to support new features. Nevertheless, the biggest problem by far was the ability for the letsencrypt.sh script to be custimised. Once customised it gets frozen in time (on systems where it was customised) and prevents us from changing anything related to the certificate issuance.

Keeping both systems competing with one another (letsencrypt.sh issuing everything in pure bash and the new system performing issuance in the directadmin service) would be worse in the long run. It is possible to keep a custom copy of an old version of letsencrypt.sh for CLI usage if one really needs it.

Our goal is to make sure ACME system works for everyone reliably and is fully functional using the web interface. There should never be a need to execute the letsencrypt.sh manually. I know the old system was not great, and most likely this is why server admins used to prefer the lower-level tool like letsencrypt.sh. The new system should remove the need for it.

In the next DA version we expect to expose the lego execution logs in the web UI. At the moment the logs are captured and saved in the user data directory but not accessible in the web UI.

Let us know if you find any corner cases where the new system could be improved! Thanks.
 
give us some cli command, sometime CLI is useful than GUI panel.
there have some issued that during move from old server hostname to new hostname ( even changed both from DA panel administrator or hostnamctl )

this command is not enough, it will request cert from both old/new hostname ( even in web panel )
Code:
letsencrypt.sh server_cert


this fixed issued and re-run above command will comeback to only new hostname request.
Code:
letsencrypt.sh server_cert serv.hostname.com

Give us some CLI that can work same as before, like : da --letsencrypt server_cert dd.hostname.com
 
Give us some CLI that can work same as before, like : da --letsencrypt server_cert dd.hostname.com
I think the best way to accomplish this is to stop thinking of Let's Encrypt as a certificate issuance and certificate installer all in one.

Let's Encrypt is just a certificate authority.

You can use the acme.sh script to request a Let's Encrypt certificate from their certificate authority for any domain. You just have to be able to handle the DCV to prove that you "own" that domain.

Once the certificate is issued - you have the certificate, private key, and required CA Bundle - you can use the DirectAdmin API to install the certificate on the domain.

Then as far as doing all of this automatically, you just run a check to find all of the certificates on your server, determining if the domain attached to that certificate still resolves to your server, and then repeating the first step - issuing a request for a Let's Encrypt certificate for that domain.

I think too often we get caught up in finding a tool that does everything and then finding that it doesn't have the granular control that is desired.

Break the process into manageable pieces:

1) A way to pass a domain (or domains if you want the certificate to have SANs) to Let's Encrypt (or any CA) and request a secure certificate. (acme.sh can do this)

2) A way to install that certificate for that domain - the DirectAdmin API is handy here (especially /usr/local/directadmin/directadmin api-url)

3) A way to check all of the certificates on a server and determine when a certificate needs to be renewed (when it's at 20 days left? 10 days left? 5 days left?) - This you kind of have to write yourself, but gives you control of how you want it to run.

There's actually very little that requires DirectAdmin for this. You just need the DirectAdmin API to install the certificate.

But once you have this framework - and since it's not built solely on a DirectAdmin requirement - you can deploy this on any type of web hosting server or control panel. Just replace the installation part.
 
I've just enabled this ACME option, and at the bottom in the 'Automatic certificate provisioning' section, it only lists my pointer domains. Is this right?
 
Back
Top