Applicable to:
- Plesk for Windows
Symptoms
- Plesk Obsidian running on a Windows Server
-
Unable to issue an SSL certificate for a domain, while getting errors that are similar to the following:
CONFIG_TEXT: Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/0.
Details:
Type: urn:ietf:params:acme:error:connection
Status: 400
Detail: Fetching http://www.acme-challenge.localhost/.well-known/acme-challenge/VZ0HZWatiUiZ_qdbOF0P8qWVhkUx44frNXXoQFsX79Q: Invalid hostname in redirect target, must end in IANA registered TLDInvalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/0.
Details:
Type: urn:ietf:params:acme:error:unauthorized
Status: 403 -
When a test.txt file is created within the
.well-known/acme-challenge
website subdirectory and we browse the URL https://example.com/.well-known/acme-challenge/test.txt, we can see the error PR_CONNECT_RESET_ERROR and the URL changes automatically to https://acme-challenge.localhost/.well-known/acme-challenge/test.txt -
The common challenge directory feature of the SSL It! extension is enabled on the Plesk server:
C:\> plesk ext sslit --common-challenge-dir -info
- Available: true
- Enabled: true
Cause
All requests to files residing within the example.com/.well-known/acme-challenge/
directory are being redirected to https://acme-challenge.localhost/.well-known/acme-challenge/, which is a hostname-based URL that does not contain a IANA registered TLD and the Let's Encrypt servers do not accept such a URL as legitimate.
Resolution
To resolve the issue, you should disable the common challenge directory function of the SSL It! extension by following these steps:
Note: This configuration may be overwritten after some Plesk version updates
-
Connect to the server via RDP
-
Disable the common challenge directory function of the SSL It! extension by executing this command:
C:\> plesk ext sslit --common-challenge-dir -disable
This will make the requests from the Let's Encrypt servers reach the domain's own ACME challenge directory and the URL will therefore be considered as legitimate during the SSL issuing process.
Comments
0 comments
Please sign in to leave a comment.