• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue [Let's Encrypt] Cannot renew the certs of wildcard domains which DNS are managed by CloudFlare.

Brownsugar

New Pleskian
This problem has affected me for a long time.
I have some domains that use the DNS managed by CloudFlare, so Let's Encrypt extension can't modify the TXT record when renewing the wildcard certs.
Any solution for this? Thanks.
 
Last edited:
This problem has affected me for a long time.
I have some domains that use the DNS managed by CloudFlare, so Let's Encrypt extension can't modify the TXT record when renewing the wildcard certs.
Any solution for this? Thanks.
Some Plesk services cannot work if DNS is not managed locally, like the local mail system with SpamAssassin, etc...

For Let's Encrypt there is a setting to switch from ACME protocol version 2 back to version 1 (Documented here: Managing Let’s Encrypt Settings at the end of the page).

Basically you can set "acme-protocol-version" to "acme-v01" in panel.ini and Let's Encrypt will use the old challenge that uses a file in a vhost directory instead a TXT value in the DNS.

Unfortunately ACME v1 does not support wildcard domains. But maybe it could be a workaround for your situation.


Until a few months ago was possible to use Plesk Let's Encrypt with wildcard support (ACME v2) and CloudFlare via the so called CNAME flattening, but then CloudFlare decided to remove the CNAME flattening from free accounts, forcing users to use CloudFlare DNS instead the local one with CNAME to cache only the "www" or other subdomain.
 
When you create an NS-record for acme-challenge.<domain> which you point to the Plesk server then Plesk is able to change the TXT-record for that domain.

I have no Cloudflare, but I do have a separate DNS-server for all my domains and have this setup working for a year now.
You do need to run Plesk's DNS service on the webserver, though.
It then only manages the acme-challenge.<domain>.

I don't know how Letsencrypt handles the A-record not pointing to the Plesk-server. Maybe it doesn't check for that when using Cloudflare.

 
Last edited:
When you create an NS-record for acme-challenge.<domain> which you point to the Plesk server then Plesk is able to change the TXT-record for that domain.

I have no Cloudflare, but I do have a separate DNS-server for all my domains and have this setup working for a year now.
You do need to run Plesk's DNS service on the webserver, though.
It then only manages the acme-challenge.<domain>.

I don't know how Letsencrypt handles the A-record not pointing to the Plesk-server. Maybe it doesn't check for that when using Cloudflare.


This works. This should be noted in the extension description.

Just add a NS record in CloudFlare (remember to delete existing "_acme-challenge" TXT record first), then solve the problem.
1627526395244.png
 
I don't know how Letsencrypt handles the A-record not pointing to the Plesk-server. Maybe it doesn't check for that when using Cloudflare.
It doesn't need to check the host when using dns-based verification. Control of DNS trumps control of host when it comes to proving ownership of the domain.
 
Back
Top