sewiti
Administrator
Domain and pointer certificates are issued separately in order to not leak information about each other.
Only the domain + subdomains, and (each) pointer + subdomains, are combined into their respective certificate.
DirectAdmin 1.706
- Thread starter sewiti
- Start date
Only the domain + subdomains, and (each) pointer + subdomains, are combined into their respective certificate.
Richard G
Verified User
How about domain name and seperate hostname entry's like domain example.com with wildcard ssl and seperate entry in DNS manager for server.example.com? Won't that give conflicts?
Because until now I just selected ftp and www etc. so no wildcard on example.com and then a seperate ssl certificate on server.example.com to prevent conflicting issues.
Because until now I just selected ftp and www etc. so no wildcard on example.com and then a seperate ssl certificate on server.example.com to prevent conflicting issues.
As a provider running many servers on DirectAdmin (9, soon 10 servers, a couple thousand sites), I want to share our recent experience with SSL, since fln asked for corner cases and I think the full story is useful.
For a while we were dealing with a recurring problem, several support tickets and customer complaints a day. Domains kept ending up in an inconsistent state: ssl=ON in the config but no certificate files, with the automatic retry looping and then giving up.
On one server we found 93 domains stuck like that, and 92 of them no longer had a .next_retry file, so DA had stopped trying and left them dead.
The worst part for us was what the customer saw: the generic "Could not execute your request" in the panel, while the real cause (Ssl::getKeyBit ... .key: No such file or directory) stayed hidden in a log they never open. That is a product-quality issue more than an ACME issue, and at our scale it quietly erodes trust in the platform.
While digging we found a second, distinct way into the same broken state: a per-domain .dnsprovider file with dnsprovider=cloudflare but empty token values. DA read it, forced DNS-01, and hard-failed with "credentials missing" instead of falling back to HTTP-01, which worked fine for that domain (it is behind Cloudflare and the challenge round-trips to the origin). So DA persisted a provider config it could not use and then refused the method that would have succeeded.
Then we updated to 1.706 and hit a third one. On one of our 1.706v servers, data/admin/letsencrypt_rate_limits/weekly.json was 0 bytes, and that blocked ALL certificate issuance on the entire server: every request failed with error=decoding data/admin/letsencrypt_rate_limits/weekly.json: EOF, same generic error for the customer. Resetting the file to [] fixed it instantly and DA repopulated it from there. Only 1 of our servers on 1.706v was affected, so it looks like an init edge case, but a single empty JSON file taking down all issuance is exactly the kind of fragility worth removing. Reading that file should tolerate empty or missing and treat it as zero usage.
Where I would push, would be:
For a while we were dealing with a recurring problem, several support tickets and customer complaints a day. Domains kept ending up in an inconsistent state: ssl=ON in the config but no certificate files, with the automatic retry looping and then giving up.
On one server we found 93 domains stuck like that, and 92 of them no longer had a .next_retry file, so DA had stopped trying and left them dead.
The worst part for us was what the customer saw: the generic "Could not execute your request" in the panel, while the real cause (Ssl::getKeyBit ... .key: No such file or directory) stayed hidden in a log they never open. That is a product-quality issue more than an ACME issue, and at our scale it quietly erodes trust in the platform.
While digging we found a second, distinct way into the same broken state: a per-domain .dnsprovider file with dnsprovider=cloudflare but empty token values. DA read it, forced DNS-01, and hard-failed with "credentials missing" instead of falling back to HTTP-01, which worked fine for that domain (it is behind Cloudflare and the challenge round-trips to the origin). So DA persisted a provider config it could not use and then refused the method that would have succeeded.
Then we updated to 1.706 and hit a third one. On one of our 1.706v servers, data/admin/letsencrypt_rate_limits/weekly.json was 0 bytes, and that blocked ALL certificate issuance on the entire server: every request failed with error=decoding data/admin/letsencrypt_rate_limits/weekly.json: EOF, same generic error for the customer. Resetting the file to [] fixed it instantly and DA repopulated it from there. Only 1 of our servers on 1.706v was affected, so it looks like an init edge case, but a single empty JSON file taking down all issuance is exactly the kind of fragility worth removing. Reading that file should tolerate empty or missing and treat it as zero usage.
Where I would push, would be:
- Make the failure paths robust. An empty or corrupt rate-limit file, or an unusable DNS provider config, should never take down issuance or dump a domain into a broken ssl=ON with no certificate. Fail safe, and surface the real reason instead of "Could not execute your request."
- Give us a CLI for the new system. I want to second Ohm J and sparek here. letsencrypt.sh request now only enables ACME, and there is no supported CLI to force a provisioning run or query per-domain status and failure reasons. For multi-server operators, web-UI-only does not scale. We rely on scripting for fleet operations, migrations, and repairs like the ones above. A CLI to enable/disable ACME per domain, force a provision, and query status would make a real difference. If there is already, do let me know, maybe i'm missing something.