Facebook
TwitterUsername:
TITLE
[Bug] ACME Extension Ignores Updated EAB Credentials – Old Account Remains Cached for Domain
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
- Plesk Version: Obsidian 18.0.81 Update #2 (Web Host Edition)
- ACME Extension Version: 1.2.0-9833
- OS: AlmaLinux 8.10 (Cerulean Leopard)
- Certificate Authority: DigiCert
PROBLEM DESCRIPTION
We regularly issue certificates from DigiCert via the ACME extension.
DigiCert provides separate sets of ACME credentials (Directory URL,
EAB Key ID, EAB HMAC Key) for each certificate product type. We use
two product types:
- Secure Site (OV)
- QuickSSL Premium (DV)
It appears that Plesk's ACME extension caches the ACME account
registered with the first-used EAB credentials, and continues to use
that cached account even after the user explicitly enters new EAB
credentials in the UI. The newly entered credentials appear to be
silently ignored.
Based on ACME protocol behavior, EAB credentials are only used during
the initial account registration. Once an account is registered, the
ACME client stores the account private key locally and reuses it for
all subsequent requests. It appears Plesk does not invalidate this
cached account when new EAB credentials are provided.
STEPS TO REPRODUCE
1. For domain example.org, submit a certificate request using the
EAB credentials for "Secure Site" (wrong product type).
→ DigiCert issues a Secure Site certificate.
2. Cancel/revoke the incorrectly issued certificate on the DigiCert
side.
3. In Plesk, click "Reissue Certificate" for example.org.
Enter the correct EAB Key ID and EAB HMAC Key for
"QuickSSL Premium" and submit.
4. (Also tested) Delete the existing certificate entry for example.org
in Plesk entirely, then start a fresh issuance using the
QuickSSL Premium EAB credentials.
Reproducibility: 100%
ACTUAL RESULT
In both step 3 and step 4, DigiCert still issues a Secure Site
certificate instead of QuickSSL Premium.
Confirmed with DigiCert Support: their logs show the request arriving
with the Secure Site EAB credentials, not the QuickSSL Premium
credentials entered in the Plesk UI.
EXPECTED RESULT
When a user enters new EAB credentials (different Key ID / HMAC Key)
in the certificate issuance UI, Plesk should:
1. Detect that the credentials differ from the previously registered
ACME account, AND
2. Register a new ACME account using the newly provided credentials,
discarding or replacing the cached account for that domain.
If Plesk intentionally reuses a cached ACME account and ignores new
EAB credentials, that behavior should at minimum be clearly documented
and the UI should display a warning. However, we believe this
constitutes a bug.
ANY ADDITIONAL INFORMATION
This issue makes it impossible to switch between DigiCert certificate
product types (or any CA that uses per-product EAB credentials) for
a domain that has previously been issued a certificate. The wrong
certificate type will always be issued regardless of what credentials
are entered in the UI.
Please investigate whether the ACME extension caches ACME account
information per domain (or per CA Directory URL), and whether that
cache is properly invalidated when new EAB credentials are provided.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Answer the question
TITLE
[Bug] ACME Extension Ignores Updated EAB Credentials – Old Account Remains Cached for Domain
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
- Plesk Version: Obsidian 18.0.81 Update #2 (Web Host Edition)
- ACME Extension Version: 1.2.0-9833
- OS: AlmaLinux 8.10 (Cerulean Leopard)
- Certificate Authority: DigiCert
PROBLEM DESCRIPTION
We regularly issue certificates from DigiCert via the ACME extension.
DigiCert provides separate sets of ACME credentials (Directory URL,
EAB Key ID, EAB HMAC Key) for each certificate product type. We use
two product types:
- Secure Site (OV)
- QuickSSL Premium (DV)
It appears that Plesk's ACME extension caches the ACME account
registered with the first-used EAB credentials, and continues to use
that cached account even after the user explicitly enters new EAB
credentials in the UI. The newly entered credentials appear to be
silently ignored.
Based on ACME protocol behavior, EAB credentials are only used during
the initial account registration. Once an account is registered, the
ACME client stores the account private key locally and reuses it for
all subsequent requests. It appears Plesk does not invalidate this
cached account when new EAB credentials are provided.
STEPS TO REPRODUCE
1. For domain example.org, submit a certificate request using the
EAB credentials for "Secure Site" (wrong product type).
→ DigiCert issues a Secure Site certificate.
2. Cancel/revoke the incorrectly issued certificate on the DigiCert
side.
3. In Plesk, click "Reissue Certificate" for example.org.
Enter the correct EAB Key ID and EAB HMAC Key for
"QuickSSL Premium" and submit.
4. (Also tested) Delete the existing certificate entry for example.org
in Plesk entirely, then start a fresh issuance using the
QuickSSL Premium EAB credentials.
Reproducibility: 100%
ACTUAL RESULT
In both step 3 and step 4, DigiCert still issues a Secure Site
certificate instead of QuickSSL Premium.
Confirmed with DigiCert Support: their logs show the request arriving
with the Secure Site EAB credentials, not the QuickSSL Premium
credentials entered in the Plesk UI.
EXPECTED RESULT
When a user enters new EAB credentials (different Key ID / HMAC Key)
in the certificate issuance UI, Plesk should:
1. Detect that the credentials differ from the previously registered
ACME account, AND
2. Register a new ACME account using the newly provided credentials,
discarding or replacing the cached account for that domain.
If Plesk intentionally reuses a cached ACME account and ignores new
EAB credentials, that behavior should at minimum be clearly documented
and the UI should display a warning. However, we believe this
constitutes a bug.
ANY ADDITIONAL INFORMATION
This issue makes it impossible to switch between DigiCert certificate
product types (or any CA that uses per-product EAB credentials) for
a domain that has previously been issued a certificate. The wrong
certificate type will always be issued regardless of what credentials
are entered in the UI.
Please investigate whether the ACME extension caches ACME account
information per domain (or per CA Directory URL), and whether that
cache is properly invalidated when new EAB credentials are provided.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Answer the question
