• Debian 11 is approaching its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.80 will be the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

SSL It! / Let's Encrypt DNS-01 challenge remains permanently "Pending" – TXT records created successfully but challenge is never confirmed

dalydesign

Basic Pleskian
Username:

TITLE


SSL It! / Let's Encrypt DNS-01 challenge remains permanently "Pending" – TXT records created successfully but challenge is never confirmed

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Product: Plesk Obsidian
Plesk version: 18.0.77
SSL It! version: 1.23.0-17655
Let's Encrypt extension version: 3.5.0-17654
Operating System: AlmaLinux 9.7
Architecture: x86_64
Mail server: Postfix + Dovecot
Server use: Primarily mail hosting; affected domains do not have their websites hosted on this Plesk server.

PROBLEM DESCRIPTION

When attempting to issue a Let's Encrypt certificate through SSL It! for mail-only domains, Plesk correctly creates a DNS-01 ACME order and generates the required TXT challenge records.

However, after the TXT records are created and are publicly resolvable, SSL It! remains permanently at Pending / Continue.

The Let's Encrypt order JSON shows that the DNS challenges have been successfully performed by Plesk:

Code:
"isPerformed": true
"isConfirmed": false
"isSuccessfully": true

The problem is reproducible and has now occurred with at least two completely separate domains:

Both domains were recently migrated to this Plesk server for mail hosting.

The authoritative DNS for these domains is external to Plesk. In the case of my domains, DNS is hosted by Cloudflare.

The required TXT records were manually copied to the authoritative external DNS and confirmed to be publicly available using both Cloudflare (1.1.1.1) and Google (8.8.8.8) resolvers, as well as from the Plesk server itself.

Despite this, clicking Continue or executing:
Code:
plesk ext sslit --certificate -issue -domain example.com -continue
only returns:

Code:
- status: pending
- message:
There is no useful error in /var/log/plesk/panel.log corresponding to the pending ACME challenge.

STEPS TO REPRODUCE

  1. Have a domain in Plesk which is being used for mail hosting but whose website and authoritative DNS are hosted elsewhere.
  2. Enable mail service for the domain.
  3. Open SSL/TLS Certificates / SSL It!.
  4. Request a Let's Encrypt certificate covering the mail services, including:
    • mail.example.com
    • webmail.example.com
  5. SSL It! requests DNS-01 validation and generates TXT records such as:
Code:
_acme-challenge.mail.example.com
_acme-challenge.webmail.example.com
  1. Add the TXT values to the domain's authoritative external DNS.
  2. Confirm that the TXT records resolve correctly publicly, for example:

Code:
dig @1.1.1.1 TXT _acme-challenge.mail.example.com +short
dig @8.8.8.8 TXT _acme-challenge.mail.example.com +short
  1. Return to SSL It! and click Continue, or execute:

Code:
plesk ext sslit --certificate -issue -domain example.com -continue
  1. SSL It! remains pending indefinitely.
The corresponding Let's Encrypt order JSON remains similar to:

Code:
{
"status": "pending",
"challenges": [
{
"type": "dns-01",
"isPerformed": true,
"isConfirmed": false,
"performedParams": {
"isSuccessfully": true
}
}
],
"confirmationType": "manual"
}

ACTUAL RESULT

SSL It! never progresses beyond the DNS-01 challenge.

The TXT records are successfully generated and are publicly resolvable, but Plesk does not appear to confirm/submit the challenges to the ACME server.

The order remains:

Code:
status: pending
isPerformed: true
isConfirmed: false
isSuccessfully: true

Running the SSL It! CLI -continue command repeatedly simply returns:

Code:
- status: pending
- message:

No useful corresponding error explaining why the challenge is not being confirmed appears in the Plesk panel log.

The same behaviour has now been reproduced with two different newly migrated domains.

EXPECTED RESULT

Once the required DNS-01 TXT records are publicly resolvable and the administrator clicks Continue, SSL It! should submit/confirm the DNS-01 challenges with Let's Encrypt.

Let's Encrypt should then validate the records, issue the certificate, and SSL It! should install and assign the certificate to the selected mail/webmail services.

If the challenge cannot be submitted or confirmed, SSL It! should return a meaningful error rather than remaining indefinitely in a pending state.

ANY ADDITIONAL INFORMATION

I confirmed that the required TXT records were visible from the authoritative DNS nameservers and from public recursive resolvers.

For example:

Code:
dig @1.1.1.1 TXT _acme-challenge.mail.example.com +short
dig @8.8.8.8 TXT _acme-challenge.mail.example.com +short

dig @1.1.1.1 TXT _acme-challenge.webmail.example.com +short
dig @8.8.8.8 TXT _acme-challenge.webmail.example.com +short

These returned the expected challenge values. The Plesk server itself was also able to resolve the correct TXT records.

Despite this, the Let's Encrypt order remained:

Code:
status: pending
isPerformed: true
isConfirmed: false
isSuccessfully: true

Importantly, I was able to bypass SSL It! and successfully obtain a certificate for the same domain using Certbot with manual DNS-01 validation.

Certbot successfully validated the DNS records and issued the certificate. I was then able to import the certificate into Plesk manually, assign it to the mail services, and confirm that the certificate was being correctly presented by the mail server.

This demonstrates that:
  • Let's Encrypt can successfully issue a certificate for the affected domain.
  • The DNS-01 TXT records are valid and publicly accessible.
  • The Plesk server can resolve the external DNS records correctly.
  • There does not appear to be a DNS propagation or Let's Encrypt validation problem.
  • The problem appears to be within the SSL It!/Plesk workflow after the TXT records have been created but before the ACME challenge is confirmed.
The issue has subsequently been reproduced on a second unrelated newly migrated domain, with the same behaviour:

Code:
isPerformed: true
isConfirmed: false
isSuccessfully: true

This therefore does not appear to be specific to an individual domain, DNS zone or Let's Encrypt order.

There may be a relationship with existing issue EXTLETSENC-1169, although I am reporting this because the problem is reproducible across multiple domains and prevents normal SSL It! certificate issuance and automatic renewal for these mail-only domains.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Help with sorting out
 
I forgot to mention that the affected domains use external DNS hosted by Cloudflare; the Plesk server is not authoritative for their public DNS zones.

As part of troubleshooting, DNS service for the domain was temporarily enabled within Plesk so that SSL It! could generate the required DNS-01 challenge TXT records. The TXT record names and values generated by Plesk were then manually copied into the authoritative Cloudflare DNS zone.

After confirming that the TXT records were publicly visible through Cloudflare's authoritative nameservers, as well as public resolvers such as 1.1.1.1 and 8.8.8.8, DNS service for the domain was disabled again in Plesk, as DNS for the domain is not hosted by this server.

Despite the correct TXT records being publicly available, SSL It! remained indefinitely in the pending state, with the challenge showing:

Code:
isPerformed: true
isConfirmed: false
isSuccessfully: true

The same DNS records were subsequently accepted by Let's Encrypt when performing DNS-01 validation manually with Certbot, and the certificate was successfully issued.

Therefore, the issue does not appear to be caused by the TXT records themselves or by DNS propagation. The failure appears to occur when SSL It! attempts to continue/confirm the pending ACME DNS-01 challenge after the required records have been published externally.
 
Back
Top