new acme ssl system insufficient for handling domain name changes

[digignosis]

From the 1.706 release notes: "The Evolution skin in this release supports only using the new ACME system."

So in the next release the other options will be back? I know they're available in the old skin, but this is just needlessly erasing much needed and unique functionality, without a viable replacement.

Here's a problem for instance: when changing a domain name via Domains > Rename domain, I'll need a new certificate, since the domain name has changed. I delete the old certificate (since it's the wrong domain name), turn on ACME, and press "Provision now".... still waiting after 14 hours, spinner spinning, and the "provision now" button stays greyed out. And there's no options to manage this otherwise.

I used to be able to simply select certificate domains (like domain.com and www.domain.com) for lets encrypt, press "save" and I'd have new, working certificate literally in 3 to 15 seconds (!)

And this is very necessary when planning domain name changes or website transfers. Please restore the professional options to handle lets encrypt certificates directly (and quickly), it can't be too much work I assume, since it's a skin-only issue.

Thank you, very much, for looking into this.

 

[sewiti]

From the 1.706 release notes: "The Evolution skin in this release supports only using the new ACME system."

So in the next release the other options will be back? I know they're available in the old skin, but this is just needlessly erasing much needed and unique functionality, without a viable replacement.

Here's a problem for instance: when changing a domain name via Domains > Rename domain, I'll need a new certificate, since the domain name has changed. I delete the old certificate (since it's the wrong domain name), turn on ACME, and press "Provision now".... still waiting after 14 hours, spinner spinning, and the "provision now" button stays greyed out. And there's no options to manage this otherwise.

I used to be able to simply select certificate domains (like domain.com and www.domain.com) for lets encrypt, press "save" and I'd have new, working certificate literally in 3 to 15 seconds (!)

And this is very necessary when planning domain name changes or website transfers. Please restore the professional options to handle lets encrypt certificates directly (and quickly), it can't be too much work I assume, since it's a skin-only issue.

Thank you, very much, for looking into this.

Could you confirm whether the ACME system is trying to issue a wildcard certificate for you, and whether that could be what's taking this long and causing the failure?
If it's failing for the wildcard certificate:
- Is the DNS zone controlled by DirectAdmin or externally?
- What DNS resolver is set up on the system where DirectAdmin is installed?

If the DNS zone is controlled externally, and DirectAdmin is set up to use local bind/named as the DNS resolver, it often confuses the ACME system into thinking it can control the DNS zone (therefore failing to issue wildcard certificates).

Proper fix is to stop using local named/bind as the DNS resolver.
An alternative quick fix would be disabling "Prefer wildcard certificates" in the ACME settings. Which forces ACME system to only use HTTP challenge.

If you have any more issues, please file a ticket so we can look into this in detail.

 

[digignosis]

Hi Sewiti,

>> "Could you confirm whether the ACME system is trying to issue a wildcard certificate for you, and whether that could be what's taking this long and causing the failure?"

The 'Prefer wildcard certificates' option is on by default. I turned it off, and that fixed the problem. Thanks

To answer your questions about the setup:

>> - Is the DNS zone controlled by DirectAdmin or externally?
These are controlled externally. Using our domain hosts nameservers.

>> - What DNS resolver is set up on the system where DirectAdmin is installed? (You suggest: Proper fix is to stop using local named/bind as the DNS resolver.)
But it was already not using local named, the /etc/resolv.conf points at external resolvers. So the external nameservers are the main issue here.

Looks like in any case, DA can't do the _acme-challenge record for the wildcard cert this way. Maybe DA could be made more robust and automatically disable wildcard certs when it detects these issues? Or disable it by default, or at least extend the page text with "Disable this when having problems / using external nameservers". For me at least it was unclear that this setting could in fact be the problem.

Hope this helps.

Another question: at some point I'd want to convert all our websites (hundreds per DA install) to ACME / disable wildcard. That's a lot of clicking, what would you recommend to update these setting for all users/domains in one go?

Thanks again!

 

[sewiti]

We will provide an official way to migrate to the new ACME system (or do it automatically) once the migration path is finalized.

 

[digignosis]

Any indication when that will be?

 

[sewiti]

Can't give any guarantees. I'd expect it to be available within a couple of DA releases.

 

[johannes]

Please is it possible to change the standard setting away from wildcard? Just optional, field to be checked manually if wildcard is desired?
We have a lot of domains on external domain provider DNS. I feel problems when my users start to use that on their own, and then blame us for what happens.. Thank you for considering (please)!

 

[Richard G]

Agree to that, we also have customers with external domains and don't want to have automatic wildcard on everything.

 

[cimaserver]

Since the last update, we have received many support tickets regarding generation issues or SSL errors; documents are not being generated, and SSL errors are occurring even though they are not yet due to expire.

 

[kevinbentlage]

It’s unbelievable that this new wildcard behavior was released as the default.

We operate many DirectAdmin VPS servers dedicated to customers. All of them rely on HTTP-01 validation because the DNS is managed externally. After this change, many domains were automatically switched to DNS-01 validation. These certificate requests are now failing because DNS validation has become the default, even though it is not supported by every server or DNS configuration.

DirectAdmin should provide a central setting in directadmin.conf that lets administrators choose the default ACME validation method—for example, HTTP-01 or DNS-01. An update should not silently change the validation method for existing installations and domains.

Setting the `admin_ssl_default_wildcard` option to `0` in directadmin.conf will not work either (tested on existing and new domains)

 

[Active8]

Why messing good working system..

 

[Richard G]

After this change, many domains were automatically switched to DNS-01 validation.

Wow, that should never happen!

 

[fln]

@kevinbentlage, the new certificate system prefers DNS challenge but does not force it. To select between DNS and HTTP challenge a test is performed before each certificate issue operation. The test compares the NS records stored locally on the DA server and NS records visible by looking up public DNS records. Most of the time this test correctly figures out that DNS is not controlled by the DA and a fallback to HTTP challenge is performed (there are more tests that can trigger the switch to HTTP challenge).

It is possible for this test to get false positives, however it usually means something very out of ordinary. Could you please open a support ticket so we check why DA did not automatically switch to HTTP challenge mode?

Things that can cause automatic challenge detection to still try DNS challenge:

• Using local bind as server default recursive resolver (configured in /etc/resolv.conf). In this scenario DA is unable to check public DNS records, because DNS requests for the domain being tested are not sent to public DNS servers.
• Having enabled ACME DNS providers configuration. In this case DA assumes DNS challenge will work, because it will use the configured DNS provider. In the next DA release we adding extra checks to not use custom DNS provider if it is partially configured (custom provider is set, but provider credentials are not set)
• Having local bind DNS server stopped or not working. In this case DA can not detect the discrepancy between local DNS records and public records. In such situation is is best to keep local bind running even if it is not being actually used.
• Creating ACME DNS challenge delegations using CNAME records. With CNAME records it is possible to allow records on other domains to be used for DNS challenge solving. This is really non-standard configuration and usually means admin knows what he is doing.

If the automatic DNS challenge availability detection does not work, the per domain ACME settings has a flag to stop preferring the DNS challenge. However for most of the servers (even if DNS zone is not managed by DA) it is safe to keep the prefer option enabled and rely on the automatic logic to switch to HTTP challenge.