@fln
this has been re-written with ai, to try to make it more clear and a lot less wall-text that what i had.
Following up on #23/#27. We run 10 DA servers, ~6,600 domains with `ssl=ON`. In the last two weeks alone we have handled **91 SSL cases**. We have now finished auditing and remediating the whole fleet, and the causes turned out to be a small number of specific behaviours. Ranked by how much damage they do to us:
---
**1. DA never adopts a certificate it did not issue, and cannot be made to.**
If a certificate arrives any other way (cPanel migration, transfer, restore), DA serves it, shows `ssl=ON` and `acme_provider=letsencrypt`, and then never renews it. Nothing in the UI or the domain config distinguishes it from a managed certificate. The only reliable discriminator we found is whether this exists:
```
/usr/local/directadmin/data/users/<user>/domains/acme_provider_cert_logs/<domain>.log
```
Fleet-wide that was **714 domains**. After filtering out those legitimately out of scope (website hosted elsewhere, or no DNS at all), **262 genuinely needed adopting**. We ran `letsencrypt.sh request` against every one:
- **141 adopted successfully.** Every single one had an already-expired certificate.
- **121 refused.** Every single one still has a valid certificate.
The split is exactly along the expiry line, which makes this a catch-22:
- While the certificate is valid, DA refuses to reissue (#24), so the domain cannot enroll.
- Once it expires, the site is already down, and only then does DA act.
On one server that ratio is 4 adopted out of 97, purely because that server's migration is more recent. Those 121 have a known break date: **7 this month, 78 in September, 33 in October.** We know exactly which sites will go down and when, and the only lever available is deleting certificate files out from under live vhosts, which we will not do at scale.
Compounding it: `admin_ssl_replace_all_expired_invalid` is the only mechanism that catches these, but with `admin_ssl_check_expiry_offset=0` it evaluates a certificate only **after** expiry:
```
Ssl::admin_ssl_should_domain_retry:<user>:<domain>: domain certificate has expired:
expiry(1785544163 - 0days(1785544163)) < now(1785544216)
```
53 seconds after expiry. That offset is not exposed in the new ACME options UI.
**Ask:** adopt unmanaged certificates at the normal renewal threshold, and/or give us `letsencrypt.sh request --force`. Who originally issued a certificate should not determine whether it gets renewed.
---
**2. The HTTP pre-check uses the local resolver, and the error message blames DNS.**
A customer created a subdomain. DA refused with:
> DNS names listed here cannot get automatic certificates because an HTTP request for these names does not reach this server. It can happen if there are no DNS records for these names or DNS records point to a different server.
All of that was false. The record existed in the zone, resolved correctly worldwide, and the ACME challenge returned HTTP 200 when fetched from an external host. The actual cause:
```
dig +short newsub.example.cl A @127.0.0.1 -> empty
dig +short newsub.example.cl A @1.1.1.1 -> <our server IP>
```
The local resolver had a **cached negative answer** from before the subdomain was created. `
www.newsub` had never been queried, so it resolved fine, and DA issued a certificate covering `
www.newsub` only, which is the one name the customer does not use. `unbound-control flush_zone` fixed it.
**Ask:** the pre-check should not trust a local recursive resolver for names the server is itself authoritative for, and the error text should say the check failed locally rather than asserting the customer's DNS is wrong. As written it sends operators and customers to debug the wrong thing.
---
**3. `letsencrypt.sh request` ignores the DNS name list it is given.**
Passing an explicit comma-separated list does not select those names. DA re-applies `letsencrypt_list_selected` and issues whatever it decides. Requesting `sub.example.cl,
www.sub.example.cl` logs `dns-names=[sub.example.cl]` and produces a single-name certificate; requesting only `mail/pop/smtp` still triggers challenges against the apex, `www` and `ftp`. We hit this three times in two days in unrelated scenarios. If the argument is documented as selecting names, it should select them, and there is currently no supported way to put a bare name and its `www` into one certificate.
---
**4. Names that pass validation are discarded when the primary name fails.**
A customer hosts their website elsewhere and uses us only for mail. `mail`, `pop` and `smtp` all validated successfully. DA threw them away:
```
debug DNS name skipped because of failed HTTP challenge check dnsName=example.cl
debug DNS name skipped because of failed HTTP challenge check dnsName=
www.example.cl
debug DNS name skipped because no valid certificate id exists to store it \
challengeType=HTTP-01 dnsName=mail.example.cl
```
A partial success becomes a total failure and the domain ends up with no certificate at all. The cPanel certificate being replaced covered exactly `cpanel/mail/webmail`, so this is clearly issuable.
Related: with DNS hosted externally (Cloudflare, in most of our cases), the default `www:mail:ftp
op:smtp` list routinely contains names that do not exist in the zone. `ftp` is the usual offender. That should be a skipped name, not a failed request.
---
None of these are exotic configurations. Items 1 and 2 in particular produce outages that we cannot prevent and that customers discover before we do. Happy to provide full logs or run diagnostics on our side.
("unbound",pid=...))