new acme ssl system insufficient for handling domain name changes

[fln]

@johannes, unchecking the "Prefer wildcard certificates" should be used only as the last resort if automatic external DNS detection does not work. Using external DNS and keeping the "Prefer wildcard certificates" ON should be ok for most of the servers. If auto-detection does not work please open a support ticket and let us investigate the server environment to find out why auto-detection had a false-positive. It would be much better in the long run to improve the auto-detection or fix the issues on your server if there are any.

 

[Imtek]

Please can you make the "uncheck the "Prefer wildcard certificates" check-box in the domain ACME settings page" a system- and userwide setting for us admins? We have all domains on external DNS and it would be many hours or even days of work to go through each customerdomain in the GUI to just uncheck it for each single domain. Thank you

+1

 

[digignosis]

We will provide an official way to migrate to the new ACME system (or do it automatically) once the migration path is finalized. Can't give any guarantees. I'd expect it to be available within a couple of DA releases.

To get back to these comments from sewiti (following my opening posts in this thread), to sum up after reading other users replies here:

- Maybe not make any big global updates before that migration path is finalized at all. Just throwing out updates like these and then saying "maybe some things that maybe helpful will happen a few releases from now, but no guarantees" is just asking for trouble.

- Instead of waiting for a vaguely planned 'official way to migrate' or again something that will just happen automatically, clearly defined admin-manageable options are needed in the short term, to be precise the following:

1. Admin actions to set all (or checkbox selected) users to acme / no acme.

2. Admin actions to set all (or checkbox selected) acme users to wildcard / no wildcard.

3. Toggles for these as global defaults in the conf files.

4. Better on-screen info text to clarify what the options do, including hints for troubleshooting the top issues.

Please pass this on to the developers.

Thanks for understanding, have a good one.

 

[Active8]

This is really bad, now we have to check each
domain /customer to see if ACME is enabled and remove the wildcard setting ?

 

[zEitEr]

domain /customer to see if ACME is enabled and remove the wildcard setting ?

A quick life-hack is here:

Run

/usr/local/directadmin/scripts/letsencrypt.sh request <domain>

in a loop against all hosted domains to enable ACME and try a certificate renewal. Be prepared to a bunch of alerts about failed attempts from DirectAdmin.

p.s. you might use a filtered list of domains, just to make sure you don't overwrite those ones which use paid certificates. In old days one could rely on an existence of the file /usr/local/directadmin/data/users/*/domains/*.cert.creation_time

 

[Active8]

Hi @zEitEr thank you for the hack so this will enable ACME and disable wildcart then.
Is there something that can be used to do all the domains at once ? like @digignosis said , we dont use paid certificates

 

[fln]

@Active8, if you do have a server where preferred-wildcard option is enabled and DA does not fallback to HTTP challenge, then please open a support ticket for us to investigate it further. Having prefer wildcard enabled and not using DNS challenge should be fine (DA should auto-detect and switch to HTTP challenge).

 

[zEitEr]

so this will enable ACME and disable wildcart then

Yes, it will enable ACME, and enable wildcard certificates, if they are configured to be used by default (not too sure there is a changeable global option for it yet)

Is there something that can be used to do all the domains at once ? , we dont use paid certificates

I would not recommend do it against all domains at once. One by one domain would be better.

The command:

awk -F: '{print $1}' /etc/virtual/domainowners

would list all hosted domains.

The following should be used for testing purposes:

for DOMAIN in $(awk -F: '{print $1}' /etc/virtual/domainowners | sort | uniq); do echo /usr/local/directadmin/scripts/letsencrypt.sh request ${DOMAIN}; done;

remove echo for actual run.

p.s. use the commands on your own risk. Though they work on my end, I don't guarantee they work the same on your server.

 

[Active8]

@fln What if we do nothing and leave it as is, DA will not renew the certificate despite it says it will be renewed after "days in Enhance skin ?

 

[fln]

@Active8, if in the domain.conf file you have acme_enabled=no (or missing), then DA will use old TLS system. It is possible to opt into the new system in one of the two ways:

• Via GUI in ACME settings page, toggle it from Disabled to Enabled.
• Execute ./letsencrypt.sh request domain.com as root.

So if you have never switched, then the old system will work as usual.

If you have switched to the new system, the new cert renew logic will be used.

If you have switched to the new system and then disabled it, the old system will start working again. But keep in mind you will likely need to reissue the ACME cert with Enhanced for the old system to start caring about the cert. This is because old system does not auto-renew certs that was not issued by it.

 

[Mika Sarmantti]

@Active8, if in the domain.conf file you have acme_enabled=no (or missing), then DA will use old TLS system. It is possible to opt into the new system in one of the two ways:
[... snip]

If you have switched to the new system and then disabled it, the old system will start working again. But keep in mind you will likely need to reissue the ACME cert with Enhanced for the old system to start caring about the cert. This is because old system does not auto-renew certs that was not issued by it.

If this is the case, and it should use the old system when domain-specific setting for ACME is off. Why is all the domains not getting new SSL certificates then? In our system, all the domains stopped fetching new SSL's after update, and we just now started waking up to the issues with increased reports of SSL certs timing out soon, unless the domain has enabled ACME setting and wildcard setting disabled? Is there some global assumption like `DA is working as DNS server` required for "old system to work as backup" Some missing LEGO piece, I'm stepping on with this?

 

[Mika Sarmantti]

Yes, it will enable ACME, and enable wildcard certificates, if they are configured to be used by default (not too sure there is a changeable global option for it yet)

[..snip]

p.s. use the commands on your own risk. Though they work on my end, I don't guarantee they work the same on your server.

This method, at least without any other steps help with disabling the wildcard setting, and thus cannot fetch the certificates. It does enable ACME but:

# ./letsencrypt.sh request customer.fi
info executing task   task=action=rewrite&domain=customer.fi&value=letsencrypt
debug comparing external NS records with local NS records acme-mode=domain domain=customer.fi local_ns=[hzns7.solinum.fi. hzns8.solinum.fi.] match=false public_ns=[ns4-08.azure-dns.info. ns1-08.azure-dns.com. ns2-08.azure-dns.net. ns3-08.azure-dns.org.] user=customer zone=customer.fi
debug NS records do not match, check for DNS challenge redirects with CNAME acme-mode=domain domain=customer.fi user=customer
debug no CNAME record, deny DNS challenge acme-mode=domain domain=customer.fi query=_acme-challenge.customer.fi. user=customer
debug executing lego command args=[run --no-bundle --force-cert-domains --no-random-sleep --ari-disable --renew-force --preferred-chain=ISRG Root X1 - -accept-tos --email=admin@server-[IP].da.direct --key-type=ec256 --server=https://acme-v02.api.letsencrypt.org/directory --path=/usr/local/directadmin/data/lego --http --http.webroot=/var/www/html --domains=customer.fi --domains=www.customer.fi --domains=ftp.customer.fi] env=[SHELL=/bin/bash EDITOR=nano PWD=/usr/local/directadmin/scripts LOGNAME=root HOME=/root LANG=en_US.UTF-8 TERM=xterm USER=root SHLVL=2 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin MAIL=/var/mail/root OLDPWD=/root _=/usr/bin/da]
info running lego              dns-names=[customer.fi www.customer.fi ftp.customer.fi] dns-provider= duration=132.022509ms exit-code=1 keytype=ec256 server=https://acme-v02.api.letsencrypt.org/directory username=customer
info finished task             duration=1.213108135s task=action=rewrite&domain=customer.fi&value=letsencrypt

 

[zEitEr]

debug comparing external NS records with local NS records acme-mode=domain domain=customer.fi local_ns=[hzns7.solinum.fi. hzns8.solinum.fi.] match=false public_ns=[ns4-08.azure-dns.info. ns1-08.azure-dns.com. ns2-08.azure-dns.net. ns3-08.azure-dns.org.] user=customer zone=customer.fi

Nameservers used for the domains (registered in whois) do not match the ones used in DirectAdmin DNS. You might need to review DNS zones and correct nameservers.

 

[Mika Sarmantti]

Nameservers used for the domains (registered in whois) do not match the ones used in DirectAdmin DNS. You might need to review DNS zones and correct nameservers.

I'll try looking into this, but I kinda fail to see the point, since the NS Servers are working as intended, namely the Azure is working as out centralized DNS service. But it is entirely possible that boss who set up DA has set skipped some important steps setting this up, and problems stem from some misconfiguration or skipped step he assumed doesn't matter as DA is not going to be a DNS server.

 

[zEitEr]

but I kinda fail to see the point, since the NS Servers are working as intended

It matters even more, if you configured your system to use local DNS for recursive lookups (check /etc/resolv.conf for it). I faced the same issue after the DA upgrade. And even if you see no point, it is worth checking. In any way, if you find another reason and a solution, you're kindly welcome to share.