Connection reset by peer on renewal

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: certbot certonly -a webroot --webroot-path=/var/www/html --agree-tos -n -d -d --email --force-renewal

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Connection reset by peer


  • The following errors were reported by the server:

    Type: connection
    Detail: Fetching
    Connection reset by peer

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My web server is (include version): nginx version: nginx/1.4.6 (Ubuntu)

The operating system my web server runs on is (include version): Ubuntu 14.04.5 LTS

My hosting provider, if applicable, is: Digital Ocean

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no


cetbot version 0.26.1

there is a redirect to https and prefixing with www (bot are going with 302)
/.well-known/acme-challenge contents are fully accessible from browser. There are no A or AAAA records in the respective NS-zone, because it’s a regular CNAME

server is listening 80,443 @IPv4, IPv6

Operational log is under the link  300  A  300  AAAA  2a03:b0c0:0:1010::1423:6001

When connecting to over IPv6, I get a “Connection reset by peer” error. Over IPv4, I get a redirect to

Are you sure that IPv6 address is correct? Are the networking configuration, firewalls, and web server configuration okay?

1 Like

Hi @nafas

there is another error: Checking

there is a redirect to

there is a http status 200, not 404. So there is not the validation file sent Letsencrypt wants to check.

there is another location for assets serving by nodejs (le.conf that included in every conf)

location ~ /.well-known {
try_files $uri $uri/ @node;
allow all;
log_not_found off;
root /var/www/html/;
location @node {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://unreel_me_backend;
proxy_redirect off;

I’ve been trying do disable ufw among all cluster hosts, issue still the same.

I think the issue is with WWW redirect, because right now I got cert with easily by invoking:

certbot certonly -a webroot --webroot-path=/var/www/html --agree-tos -n -d --email

Then you must tell Certbot the root of this directory, so certbot can create the validation file under


PS: Remove your ipv6 - AAAA entry.

Validationfiles are being created and served correctly, tried that several times. Anyways, thanks for suggestion, Herr Auer

There is no AAAA or A entries at all. Only CNAME and ALIAS

My own tool says - no.

Letsdebug says - no:


Error has an AAAA (IPv6) record (2a03:b0c0:0:1010::1423:6001) but a test request to this address over port 80 did not succeed. Let's Encrypt will prefer to use AAAA records, if present, and will not fall back to IPv4 records. You should either ensure that validation requests to this domain succeed over IPv6, or remove its AAAA record.

Get read tcp [2600:3c03::f03c:91ff:fea2:6a56]:56588->[2a03:b0c0:0:1010::1423:6001]:80: read: connection reset by peer

@0ms: Making a request to (using initial IP 2a03:b0c0:0:1010::1423:6001)
@0ms: Dialing 2a03:b0c0:0:1010::1423:6001
@173ms: Experienced error: read tcp [2600:3c03::f03c:91ff:fea2:6a56]:56588->[2a03:b0c0:0:1010::1423:6001]:80: read: connection reset by peer



A test authorization for to the Let's Encrypt staging service has revealed issues that may prevent any certificate for this domain being issued.

Fetching Connection reset by peer and have different IP addresses.          266   A          266   AAAA   2a03:b0c0:0:1010::1423:6001      1779  CNAME  1779  A  1779  AAAA   2604:a880:2:d0::4a54:a001

I still get a “connection reset by peer” error on's IPv6 address.

1 Like

Let me check, it looks like NS1 balancer has sent the redirect to another cluster member. Thanks for the hint

Yes, both addresses are our, and both hosts have the same shared root folder for serving challenges. It’s weird, that second host doesn’t return requested data

Thanks a ton! I found a glitch it the default_server statement listen directive on the host - there was

listen [::]:80 ssl;

My apologies for disturbance. Have a good one!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.