• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue LetsEncrypt suddenly became reliant on DNS extension

mr-wolf

Silver Pleskian
Plesk Guru
After enabling the wildcard support I tested this on a server and got this error

Error: Could not issue a Let's Encrypt SSL/TLS certificate
Remove DNS record failure: DNS service is not enabled


I don't know (yet) if I can revert this by disabling wildcard-support, but if NOT I will have a huge problem

None of my servers have DNS enabled.
They are on a separate Plesk server for years.

If this change can not be reverted this has to be fixed ASAP...

EDIT
I just removed the entry out of /opt/psa/admin/conf/panel.ini
It turns out this problem is only there if I have enabled the wildcard feature.
At least there is no panic now.

I would like to know how the LetsEncrypt wildcard feature works and if it can be made so it works without the DNS on the server.
 
Last edited:
Hmmm will not realy help you but I have now 2 different Test Servers (Centos 7 & Ubuntu 16.04) running with wildcard enabled and so far no recognizeable issue. But on both I have DNS enabled.

Perhaps it has to do with the new TXT Record _acme-challenge.mydomain.de. which is new established
 
Last edited:
Wildcard Cert support is based upon DNS verfication, as it's not feasibly to use a HTTP request to check for the ownership/control of a domain.
So in order to create that specific DNS entry, the LetsEncrypt extention needs to have access to the domains DNS configuration.

As far as I know (did not read into the details), in Plesk's case this change in behaviour is triggered by using the v2 API of ACME protocol and switching to DNS verification generally, regardless of the type of certificate. (wildcard or not)

I would wish for Plesk to give us the option to choose which verification method is used, as with the v2 API it's possible to have either DNS or HTTP verification.
Sure, for wildcard certs only DNS will work (so with "external" DNS servers you are out of luck anyway), but for "normal" certs the legacy HTTP check is still a valid and great option.
 
After enabling the wildcard support I tested this on a server and got this error

Error: Could not issue a Let's Encrypt SSL/TLS certificate
Remove DNS record failure: DNS service is not enabled


I don't know (yet) if I can revert this by disabling wildcard-support, but if NOT I will have a huge problem

None of my servers have DNS enabled.
They are on a separate Plesk server for years.

If this change can not be reverted this has to be fixed ASAP...

EDIT
I just removed the entry out of /opt/psa/admin/conf/panel.ini
It turns out this problem is only there if I have enabled the wildcard feature.
At least there is no panic now.

I would like to know how the LetsEncrypt wildcard feature works and if it can be made so it works without the DNS on the server.

@mr-wolf

It can do no harm to enable DNS on the Plesk instance(s), even if you have external DNS servers (which is recommended anyway).

That is the theory, but somehow you have some indications that real life is a little bit different.

In essence, if one or more of the subdomains (covered by the wildcard stanza) is not pointing to one and the same server, then an issue can or even will arise.

Can you be so kind to file a bug report?

After all, the following applies:

1 - this issue is not desirable behaviour for the Let's Encrypt extension: failing to secure all subdomains due to a failure related to one or more specific subdomains is bad,

2 - the Let's Encrypt extension should be able to loop through various subdomains that are on the server hosting the Plesk instance,

3 - the Let's Encrypt extension should NOT be attempting to secure specific subdomains if they are not on the server hosting the Plesk instance,

4 - the Let's Encrypt extension should be able to allow external DNS servers: external DNS servers are part of a proper configuration (for many reasons),

5 - the HTTP verification method should really be sufficient on any Plesk instance, certainly when taking points 1 to 4 into careful consideration.


I would appreciate it very much if you would file a bug report!

Regards.......
 
I would like to use the new wildcard certificate feature of Lets Encrypt to cover a subdomain used for email connections. I encountered the same error - Remove DNS record failure: DNS service is not enabled - but I already have an external DNS service and do not want to switch on DNS on the same server in case it generates unexpected behaviour. I don’t understand why the external DNS can’t be used for wildcard certificates. Apparently it has been recognised as a bug - Bug EXTLETSENC-558 is confirmed - however that was 11 months ago so why hasn’t it been addressed yet?
 
I just hope you realize that even if Plesk would implements a solution that makes manual validation with external DNS possible, you would have to manually renew the certificate and re-do these steps every three months.

That said, at least for "testing" purposes I could have used such a manual validation in the past as well. (for example If I wanted to migrate a website from one to server to another)
 
Why would it be any different to the standard www+domain certificates which are auto-renewed when required using the daily cron jobs?
 
These "standard" certificates get verified via http validiation, unlike wildcard certs that rely on the LetsEncrypt DNS validation method
 
Well that's the point of the discussion isn’t it... the DNS validation doesn’t use the external DNS service... which it could do (like everyone else already does)

Nothing at all to do with the way certificates are renewed - manual or auto-renewal - which isn't the issue here
 
Simply put, the DNS validation doesn’t work with external DNS services, because it can't get automated*
For every issue and/or renewal there is a new and different token to be configured on the DNS, so as long as Plesk has no access to this DNS server, it will be a manual process no matter what.


* that is up for discussion, because for some external DNS services (Route53 for example) exist API's, that would allow automatic processing through Plesk.
 
* that is up for discussion, because for some external DNS services (Route53 for example) exist API's, that would allow automatic processing through Plesk.

wouldn't the relatively new domainconnect also help with this? Connect up with the DNS provider and Plesk's creation of the DNS entries would be replicated to the proper DNS servers. As long as Plesk lets ecnypt extension supports this.
 
I think there is an additional issue with updates of extension(s). It seems that the SSL module (or maybe another one, unclear yet) is throwing an error on update attempts that it cannot be udpated due to the missing DNS module. So most obviously the DNS module can no longer be optional but obligatory? Has anyone else seen that error messages after nightly maintenance when logging on to the admin console in the morning?
 
@mr-wolf
I just removed the entry out of /opt/psa/admin/conf/panel.ini
It turns out this problem is only there if I have enabled the wildcard feature.
At least there is no panic now.
Could you please post what exactly needs to be entered into the panel.ini file so that the wildcard feature is disabled?
 
Back
Top