DirectAdmin 1.707

I can confirm that if this option is empty:
Code: 
acme_enabled=
in the file like:
Code: 
/usr/local/directadmin/data/users/[DA_USER]/domains/[DOMAIN_NAME].conf
then DA Panel shows such error:

Manage certificates
Unable to retrieve data due to the following reason: "Server Error: unexpected error, please check server error log for more details". Click "Retry" to try again.

But the error is actual only for 1 DA user and only for 1 domain.
And it is completely different in this case and not the one that was shown us above.
 
@romans, stop confusing people. The error Server Error: unexpected error, please check server error log for more details is normal for malformed configuration files. And as the message tells the details are in the server logs. You can achieve it by setting malformed value to any of the domain.conf file fields. But in the service log you will find the reason why file was not parsed successfully.

It is not the same as A <SelectItem /> must have a value prop that is not an empty string..... This is UI error.
 
fln said:
@Zhenmue, stop spamming the forum with AI hallucinations (slop). Your answer is completely wrong. Missing config entry has nothing to do with this error. Users to do NOT NEED to enable new system for the ACME settings page to work.

You message here is outright harmful. Please do post anything you have not verified manually.

Stop Sloppypasta: Don't paste raw LLM output at people

Sloppypasta: verbatim LLM output pasted at people. Why it's rude and what to do instead.
stopsloppypasta.ai

@virtio, @ASUS, could you please open a support ticket so we could inspect the configuration of you server.

If I had to guess, I think it will have something to do with the malformed data/admin/dnsproviders.json file. By malformed I mean not just missing file or invalid JSON. I mean having valid structure with empty dictionary keys. We would really like to find out how this happened. The dnsproviders.json file can be regenerated (synced with lego tool) with the da build lego command.
Click to expand...

The previous response, to wich you replied to, was early debugging of DirectAdmin issues and bugs on SSL system, cause by da releases. Same issue 2 other people shared here, and is a brand new bug by .707 version... wich already had us over 7 cases in 2 days, so "sorry for early debug" of your product issue...


GET /api/session/acme-dns-providers returns a garbage first element — {"id":"","name":"","variables":[]} — on any server whose data/admin/dnsproviders.json contains an empty-key entry ("": {"name":"", ...}). Some older catalog builds shipped it (ours were dated Oct 2025–Jan 2026).
The 1.707 Evolution frontend renders one &lt;SelectItem&gt; per provider and crashes on the empty id , that's the error, manually and humanly verified by me.
Removing the empty entry fixes the page instantly. Reproducible without root as already explained.

Not sure what part of the real issue, information and fix hurted you so bad.

This was found and verified manually, by me, on several of 10 production servers through several weeks of 1.706/1.707 regressions.
If the response to an imperfect first report is a public "stop spamming slop" instead of "that's not correct, what else did you find"
You will get fewer replies, less feedback, and a worst product at the end, but is your product, your choice.

Yes, we use AI Claude only for DirectAdmin SSL ISSUES because between the lack of documentation and the bugs your updates keep introducing, we've had to work through 150+ SSL cases on our fleet in the past few weeks.
That's real extra work your changes created for providers, and we did it while filing you reproducible reports.
We have even created a "yes ai script" our staff can use to fix domains/accounts on our DA Fleet where clients can't get their SSL certificates trough the GUI, and that script alone has been used 96 times these past few weeks by the rest of the staff... so you tell me about a broken feature.

Being rude in public to defend a buggy release is not professional support. You could address the issues raised in this thread and in our support ticket, where we were promised fixes for these issues, were we did provided not-needed SSH access. Instead you chose "stop spamming slop."

I was spending my own time here trying to help the product.
If this is how DirectAdmin staff treats the people doing that, I'm done with this forum.
 
Zhenmue said:
Not sure what part of the real issue, information and fix hurted you so bad.
Click to expand...

I am sure you had no bad intentions with the AI slop message. Yet it caused some.

The reason that slop message is harmful is because it says that not having the acme_enabled line in domain config causes problems. In reality it does not cause any problems and it is perfectly fine to not have it. Actually all of the domains that have not yet switched to the new TLS system do not have this field.

If someone were to trust this is a problem, they could cause more problems by manually adding it.

A good example of how this causes problems is already illustrated by @romans message. You have tricked him into thinking there are problems with this field. As long as people are not manually tampering with domain conf file, it is not possible to end up with malformed acme_enabled field value. It is not a bug, but a desired behaviour for DA to refuse to work if it can not decode the configuration file.

I am sorry if that sounds rude, but let me state it clearly again. Please do NOT paste any AI slop in this forum. This message is not just for you personally. It is also for all of the forum users. The reasons why it is very harmful are quite precisely captured in the article I have linked before:

Stop Sloppypasta: Don't paste raw LLM output at people

Sloppypasta: verbatim LLM output pasted at people. Why it's rude and what to do instead.
stopsloppypasta.ai

Zhenmue said:
Some older catalog builds shipped it (ours were dated Oct 2025–Jan 2026).
Click to expand...
This is the piece of information we were trying to acquire by getting access to the affected servers. Thank you 🙇‍♂️.

With this information at hand we can confirm that the fix for this problem is upgrading the lego with the da build lego command.
Zhenmue said:
.. the bugs your updates keep introducing, ... script alone has been used 96 times... so you tell me about a broken feature.
Click to expand...
So far the new TLS system had only one bug reported and fixed. This is a support for a custom webmail vhost (created with custom webserver config) using the main domain certificate. This fix was released with DA 1.707. Maybe we will have more in the future, but not yet.

I think I understand how you feel. For you a complaint from the end user is a bug or a problem. From this perspective any change is a problem. It does not matter if it will be better or worse in the long run, as long as you have to react to it - it is a problem.

The new TLS system exposes the already existing problems on heavily customised servers with the goal of streamlining the TLS configuration. Most of the users who have not manually tampered with config files, who do not have malformed DNS configuration, and who have not used letsencrypt.sh for non-standard configurations have no problems at all. This effort to streamline how it works will enevitably force non-standard usage patterns to have to be adjusted.

If there are any changes we could make to help you with the problems you are having, please let us know! For example, we have received a report that some users had a custom DNS provider configured without any environment variables. The UI was extended to show supported configuration options and not use custom DNS provider without environment. It makes it harder to misconfigure the custom DNS provider, it is still possible thou. We do not consider this to be a bug fix.

Zhenmue said:
You could address the issues raised in this thread and in our support ticket, where we were promised fixes for these issues
Click to expand...
I am not sure what kind of fixes or issues you are referring to.

At the moment we are working on quality-of-life improvements for the TLS system but not bugs. If you think some of the reported problems have not reached the dev team and were lost in the support system, feel free to PM me the ticket numbers directly. I would check them out.
 
fln said:
@Zhenmue, stop spamming the forum with AI hallucinations (slop). Your answer is completely wrong. Missing config entry has nothing to do with this error. Users to do NOT NEED to enable new system for the ACME settings page to work.

You message here is outright harmful. Please do not post anything you have not verified manually.

Stop Sloppypasta: Don't paste raw LLM output at people

Sloppypasta: verbatim LLM output pasted at people. Why it's rude and what to do instead.
stopsloppypasta.ai

@ofisimo, @ASUS, could you please open a support ticket so we could inspect the configuration of you server.

If I had to guess, I think it will have something to do with the malformed data/admin/dnsproviders.json file. By malformed I mean not just missing file or invalid JSON. I mean having valid structure with empty dictionary keys. We would really like to find out how this happened. The dnsproviders.json file can be regenerated (synced with lego tool) with the da build lego command.
Click to expand...
Thank you for the advice. I logged in via SSH and ran da build lego as suggested. The command completed successfully.

Interestingly, I compared the original dnsproviders.json with the newly generated one using WinMerge, and the tool confirmed: 'Selected files are identical!' There were no empty dictionary keys in the backup file.

However, after running the command, everything else seems to be working fine now (my Evo skin is fully back to normal). I will keep an eye on it, but we can consider the main issue resolved for now.

One quick question: I noticed that under the DNS Provider configuration, both CF_DNS_API_TOKEN and CF_ZONE_API_TOKEN are now empty. Do I need to re-enter these tokens for the configuration to take effect?
Thanks again for your support!
 
Last edited:
Zhenmue said:
AI Summary related to what ASUS and ofisimo shared.

ACME Settings page crashes in Evolution on 1.707 when the domain conf lacks acme_enabled (affects ~90% of pre-existing domains)

Environment: DirectAdmin 1.707 (build dfe8f827), CloudLinux 9, Evolution skin. Reproduced across 9 independent servers.

Symptom: Opening ACME Settings for a domain shows: Unable to retrieve data due to the following reason: "A &lt;SelectItem /&gt; must have a value prop that is not an empty string..." — Retry does nothing.

Root cause (no root access needed to verify): the page crashes for every domain whose data/users/USER/domains/DOMAIN.conf does not contain the acme_enabled= key. That is the normal state for any domain that never went through the new ACME enablement — on our servers that's ~90% of all domains (6,042 of 6,705 across 9 boxes). Domains that do have acme_enabled=yes render the page fine.

Repro: take any domain conf without acme_enabled (or remove the key on a test domain) and open ACME Settings in Evolution on 1.707 → crash.

Workaround per domain: run /usr/local/directadmin/scripts/letsencrypt.sh request DOMAIN (proper enablement — writes acme_enabled=yes and provisions), or append acme_enabled=yes to the domain conf. Both make the page load again.

Suggested fix: the frontend Select should fall back to a default when acme_enabled is absent/empty (it's the majority state on upgraded servers), and Retry should re-render after the fix.
Click to expand...
Thank you for your help! I logged in via SSH and executed da build lego as fln's suggested. The command completed successfully.
 
@ASUS, depends.

If you domain is actually managed by CloudFlare, you can enter API key and DA will be able to issue wildcard TLS certificates.

If your domain is not manager by CloudFlare, or it is managed but you do not want wildcard certificates or do not want to give API access to DA it would be best to clear custom DNS provider configuration. Click the yellow "Clear" button under DNS provider selector and then "Save changes" button.
 
Hi,

Legacy license.

Updated a server to version 1.707 earlier today. Immediately after the update my browser started to complain that my server's Let's Encrypt certificate is invalid. Checking in the browser it told me that DA is using a certificate from 2021.
The menu option "Server TLS certificate" said that I have a valid Let's Encrypt cert, to expire somewhere next month.
I told it to renew anyways.. That did not help.
Looked at the directadmin.conf values apachecert, apacheconf and apachekey and they all are the recommended defaults.
eg.
Code: 
apachecert=/etc/httpd/conf/ssl.crt/server.crt
apacheconf=/etc/httpd/conf/extra/directadmin-vhosts.conf
apachekey=/etc/httpd/conf/ssl.key/server.key

The server.crt file is indeed from today and the server.combined file in that same folder does include the contents of that file.
Weird? Not sure where else it might be grabbing the wrong contents for directadmin itself.
 
@wila, the main server hostname TLS certificates are stored in /usr/local/directadmin/conf directory. The location of server certs are no longer configurable since DA 1.680. If you are getting cert error when accessing DA panel (port 2222) these are the files that should be checked. The "Server TLS certificate" page on admin level can update these files.

If the certificate problem is not for DA panel itself, but for apache webserver (port 443). Then files in apache config folder should be checked (the ones mentioned in your post). Usually after DA issues new cert for itself it calls da build sync_server_cert command and CB copies it for the web, mail, ftp services.

It means on servers with standard configuration the certs in /usr/local/directadmin/conf directory should be the same as in /etc/httpd/conf/ssl.crt:

Code: 
# diff -b /usr/local/directadmin/conf/cakey.pem  /etc/httpd/conf/ssl.key/server.key
# diff -b /usr/local/directadmin/conf/cacert.pem  /etc/httpd/conf/ssl.crt/server.crt
# diff -b /usr/local/directadmin/conf/carootcert.pem  /etc/httpd/conf/ssl.crt/server.ca
# diff -b <(cat /usr/local/directadmin/conf/cacert.pem; echo ""; cat /usr/local/directadmin/conf/carootcert.pem)  /etc/httpd/conf/ssl.crt/server.crt.combined

If this does not help, please open a support ticket. Maybe there is something very non-standard on your server.
 
Shouldn't be non standard, but maybe there's something I forgot about.
The above didn't help I'm afraid. Also ran the da build sync_server_cert and da build lego commands earlier to no avail.
Had hoped to be able to resolve it myself, but alas, I've created a ticket instead as I'm clearly missing something.
 
Last edited:
@fln was right, there was something very non standard.

I had created a subdomain for the main server domain (as admin --> user menu --> account manager --> subdomain management) and totally forgot about that. That subdomain should never have been there, deleted it, followed up by:

Code: 
  systemctl restart directadmin
  da build rewrite_confs
  da build sync_server_cert

Thanks Roman for the swift troubleshooting while I continue here to hang my head in shame.
 
You must log in or register to reply here.
Back
Top