• The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • Debian 11 has reached its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.81 is 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 installs incomplete Generation Y RSA certificate chain (YR1/YR2 → Root YR) without Root YR cross-sign to ISRG Root X1

learning_curve

Golden Pleskian
Username:

TITLE

SSL It! / Let's Encrypt installs incomplete Generation Y RSA certificate chain (YR1/YR2 → Root YR) without Root YR cross-sign to ISRG Root X1

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Product: Plesk Obsidian
Plesk version: 18.0.81 Update 2
Operating System: Ubuntu 26.04.1 LTS
Architecture: x86_64
SSL It! version: 1.24.0-19585
Let's Encrypt extension version: 3.5.1-19593
Web server: nginx + Apache
The issue remains reproducible with SSL It! 1.24.0-19585 and Let's Encrypt extension 3.5.1-19593, after updating both extensions to their current installed releases.

PROBLEM DESCRIPTION

When SSL It! obtains a current Let's Encrypt RSA certificate issued from the new Generation Y hierarchy, Plesk installs a certificate chain which stops at the new Root YR hierarchy without including the available cross-signed Root YR → ISRG Root X1 certificate.

A representative certificate issued through SSL It! has:
Code:
Leaf issuer:
C=US, O=Let's Encrypt, CN=YR1
The CA bundle installed by Plesk contains only:
Code:
subject=C=US, O=Let's Encrypt, CN=YR1
issuer=C=US, O=ISRG, CN=Root YR
Equivalent behaviour has also been observed with certificates issued through YR2.

No certificate linking Root YR to the already widely trusted ISRG Root X1 is included in the Plesk-installed CA bundle.

Let's Encrypt currently documents that chains terminating at Root YR are not expected to work with the major trust stores because that root has not yet been incorporated into them. Let's Encrypt also publishes Root YR cross-signed by ISRG Root X1, and states that chains terminating at ISRG Root X1 provide greater compatibility. Let's Encrypt

Manually adding that official cross-signed certificate changes the CA bundle to:
Code:
subject=C=US, O=Let's Encrypt, CN=YR1
issuer=C=US, O=ISRG, CN=Root YR

subject=C=US, O=ISRG, CN=Root YR
issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1
The leaf certificate itself is unchanged.

For a representative affected certificate, the original Plesk certificate and the manually corrected certificate had the same:
Code:
serial number
SHA-256 fingerprint
private key
The material difference was the CA bundle.

This therefore appears to be a certificate-chain selection / installation issue in SSL It! / the Let's Encrypt extension, rather than a certificate issuance failure.

STEPS TO REPRODUCE

1) Use a current Plesk Obsidian installation with:
SSL It! 1.24.0-19585​
Let's Encrypt extension 3.5.1-19593​
2) Issue or renew a normal RSA Let's Encrypt certificate for a hosted domain through SSL It!.
3) Allow Let's Encrypt to issue the certificate from the current Generation Y RSA hierarchy (YR1, YR2, etc.).
4) Inspect the chain stored by SSL It!, for example:
Bash:
openssl crl2pkcs7 -nocrl \
  -certfile /opt/psa/var/modules/sslit/etc/live/<DOMAIN>/chain.pem \
  | openssl pkcs7 -print_certs -noout
5) Observe that the chain contains the issuing intermediate, for example:
Code:
subject=C=US, O=Let's Encrypt, CN=YR1
issuer=C=US, O=ISRG, CN=Root YR
but does not contain:
Code:
subject=C=US, O=ISRG, CN=Root YR
issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1
6) Optionally inspect the chain presented by the web server:
Bash:
openssl s_client \
  -connect <DOMAIN>:443 \
  -servername <DOMAIN> \
  -showcerts </dev/null
7) Obtain the official Root YR certificate cross-signed by ISRG Root X1 from Let's Encrypt.
8) Append that certificate to the existing CA bundle.
9) Import/update the same leaf certificate and private key in Plesk using the expanded CA bundle.
10) Reinspect the certificate chain.
The resulting chain now contains:
Code:
YR1 / YR2
   ↓
Root YR
   ↓
ISRG Root X1
instead of terminating at Root YR.

ACTUAL RESULT

SSL It! installs a chain equivalent to:
Code:
Leaf certificate
   ↓
Let's Encrypt YR1 / YR2
   ↓
Root YR
but does not include the available Root YR certificate cross-signed by ISRG Root X1.

Let's Encrypt's current chain documentation states that chains terminating at Root YR are not expected to work with major trust stores at present. Let's Encrypt

The certificate itself is valid and correctly issued. The problem is specifically the CA chain installed by Plesk.

EXPECTED RESULT

While Root YR is not yet generally trusted by major root programs, SSL It! should request or install a Let's Encrypt chain that terminates at the established ISRG Root X1 trust anchor.

For Generation Y RSA certificates this should be equivalent to:
Code:
Leaf
   ↓
YR1 / YR2
   ↓
Root YR cross-signed by ISRG Root X1
   ↓
ISRG Root X1
Alternatively, SSL It! should expose a supported mechanism for selecting the preferred Let's Encrypt chain.

Automatic renewal should preserve that compatible chain.

Let's Encrypt documents that ACME clients may need to select an alternate chain where multiple valid chains exist, and specifically notes that chains ending at ISRG Root X1 offer the greatest compatibility. Let's Encrypt

ANY ADDITIONAL INFORMATION

The behavior has been observed on multiple unrelated certificates hosted on the same Plesk server.

Both YR1 and YR2 issuing intermediates have been observed.

For one representative affected certificate:
Code:
Original Plesk leaf certificate:
- same serial number as corrected certificate
- same SHA-256 fingerprint as corrected certificate
- same private key

Difference:
- CA bundle only
Original Plesk CA bundle:
Code:
subject=C=US, O=Let's Encrypt, CN=YR1
issuer=C=US, O=ISRG, CN=Root YR
Corrected CA bundle:
Code:
subject=C=US, O=Let's Encrypt, CN=YR1
issuer=C=US, O=ISRG, CN=Root YR

subject=C=US, O=ISRG, CN=Root YR
issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1
The cross-signed certificate used for testing is the official Let's Encrypt/ISRG certificate:
Code:
Subject:
C=US, O=ISRG, CN=Root YR

Issuer:
C=US, O=Internet Security Research Group, CN=ISRG Root X1
In the tested environment its validity was:
Code:
notBefore=May 13 00:00:00 2026 GMT
notAfter=Sep 2 23:59:59 2032 GMT
Let's Encrypt's published certificate hierarchy confirms that Root YR has an official cross-signed certificate issued by ISRG Root X1, and that Root YR itself is not yet included in root-program trust stores. Let's Encrypt

As a workaround, separate corrected certificate objects were created in Plesk using the same leaf certificate/private key and the expanded CA bundle.

Those corrected objects work correctly, but they sit outside the normal SSL It! renewal lifecycle. An additional synchronization mechanism is therefore required after SSL It! renews the original certificate.

No real domain name, IP address, certificate repository ID, ACME order ID or account-specific identifier is included in this public report.

EXPECTATIONS FROM PLESK SERVICE TEAM (prompt below - detail here)

Please investigate whether SSL It! / the Let's Encrypt extension is selecting or installing an unsuitable Let's Encrypt chain for certificates issued from the new Generation Y RSA hierarchy.

Please reproduce issuance using YR1 / YR2 and verify whether Plesk installs only:
Code:
YR1 / YR2 → Root YR
rather than the broadly compatible alternative:
Code:
YR1 / YR2 → Root YR cross-signed by ISRG Root X1
If confirmed, please update SSL It! / the Let's Encrypt extension so that:
  1. the compatible ISRG Root X1 chain is selected while Root YR is not yet generally trusted; or
  2. administrators are given a supported way to select the preferred Let's Encrypt chain; and
  3. automatic renewals preserve that chain selection.
This report follows the Plesk Reports forum's requirement that reports be reproducible bugs rather than general support requests.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
Back
Top