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.
 
@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.



@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.

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.
 
Not sure what part of the real issue, information and fix hurted you so bad.

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:



Some older catalog builds shipped it (ours were dated Oct 2025–Jan 2026).
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.

.. the bugs your updates keep introducing, ... script alone has been used 96 times... so you tell me about a broken feature.
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.


You could address the issues raised in this thread and in our support ticket, where we were promised fixes for these issues
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.
 
Back
Top