ACME Validation failed when generating a Let's Encrypt Certificate with error: "Connection reset by peer", "status": 400"

When attempting to generate a new Let's Encrypt Certificate (LE Cert) for a Virtual Service (VS) the LE Cert generation fails with the following error observer in the system logs: "Connection reset by peer", "status": 400". This article will cover the cause and fix for this issue.

Nov 7, 2024
Knowledge

Title

URL Name

ACME-Validation-failed-when-generating-a-Let-s-Encrypt-Certificate-with-error-Connection-reset-by-peer-status-400

Article Number

000270377

Environment

Product: LoadMaster Version:7.2.53 and above Platform:Any Application:Any

Question/Problem Description

When trying to generate a new LE Cert for a VS the LE Cert generation fails with error: "Connection reset by peer", "status": 400"

What is the cause of the issue and how can it be resolved.

Steps to Reproduce

Clarifying Information

Error Message

2023-04-30T15:30:25+03:00 <LoadMaster_hostname> Acme: Validation failed for {"type": "dns","value": "example.domain.com"}: { "type": "http-01", "status": "invalid", "error": { "type": "urn:ietf:params:acme:error:connection", "detail": "52.42.25.12: Fetching http://example.domain.com/.well-known/acme-challenge/<tokenValue>:Connection reset by peer", "status": 400 }, "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/<Account ID>/<randomValue>", "token": "<tokenValue>", "validationRecord":[ { "url": "http://example.domain.com/.well-known/acme-challenge/<tokenValue>", "hostname": "example.domain.com", "port": "80", "addressesResolved": [ "52.42.25.12" ], "addressUsed": "52.42.25.12" } ], "validated": "2023-04-30T15:30:45Z" } (code: 13)

Defect Number

Enhancement Number

Cause

The cause of the issue is a misconfiguration in the initial set-up of the virtual service.

In order for the LE Cert to be generated successfully the targeted Virtual Service of the LE Cert must be set up in a specific way in order to work as intended.

In this case the error "Connection reset by peer", "status": 400" is being made in reference to the port 80 redirect VS as indicated by the following log: "port": "80"

If there are real server configured on the port 80 redirect then the LE Cert Generation will fail.

This is because the LE Cert bot will always send the first request of HTTP/80 to initialize the connection.

After the first request is sent over port 80 it is expected that there will be a redirect to port 443 since all follow up communication by the cert bot will occure over HTTPS/443.

If there are real server configured on the port 80 redirect virtual service then the first LE Cert Bot will be sent to the real server and the redirect to 443 will never trigger.

As a result the follow up request will be forwarded over HTTPS/443 to the real server over port 80 where the "Connection reset by peer" will trigger.

Resolution

To resolve the issue ensure that there are no real servers configured on the Port 80 redirect virtual service.

Here are the VS configuration requirements when setting up a VS for Let's Encrypt Certificate Generation:

There must be a VS deploy on Port 443.
The 443 VS must have SSL Acceleration enabled.
The 443 VS must have a Sub-Virtual Service (SubVS) Configured.
Content Switching must be enabled under the Advance Properties of the 443 VS. (Advanced properties --> Content Switching --> Enable)
At minimum the Default rule must be assigned the SubVS (443 SubVS --> Rules --> Add Rule --> Default.)
The real servers must be configured on the 443 SubVS.
There must also be a port 80 redirect VS configured under the same IP address as the 443 VS.
There must not be any real server configured under the port 80 redirect VS.
Not Available Redirect Handling must be enabled under the port 80 redirect VS. (80 VS --> Advanced Properties --> Not Available Redirection Handling --> error Code: 302 --> Redirect URL: https://%h%s )