Error Connection Reset by Peer after Renewing


#1

I have the following errors when try to renew my certificates:
Failed authorization procedure. www.aguadilla.inter.edu (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Connection reset by peer, aguadilla.inter.edu (tls-sni-01): urn:acme:error:connection :: The se rver could not connect to the client to verify the domain :: Connection reset by peer, eavia.aguadilla.inter.edu (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Connection reset by peer

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: www.aguadilla.inter.edu
    Type: connection
    Detail: Connection reset by peer

    Domain: aguadilla.inter.edu
    Type: connection
    Detail: Connection reset by peer

    Domain: eavia.aguadilla.inter.edu
    Type: connection
    Detail: 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.

I’ll check my domain, dns, my firewall and everything look OK.

I don’t know what happened.
Please help.


#2

Hi @jomorales,

This does look like a firewall problem, but not a usual one.

Using the TLS-SNI-01 method (which has been phased out for new certificate issuance but is still allowed for renewals, like yours), the certificate authority will try to connect to your server and use the TLS SNI feature to request a particular nonexistent servername, ending in .acme.invalid.

For some reason your server (or a firewall in between the Internet and your server) absolutely refuses to continue TLS negotiations for invalid servernames. This is different from the default behavior of most web servers.

openssl s_client connect aguadilla.inter.edu:443 -servername aguadilla.inter.edu completes the connection and returns the old expired certificate

openssl s_client connect aguadilla.inter.edu:443 -servername example.acme.invalid just times out and disconnects, without returning any certificate at all (on almost all servers, it would return some default certificate, maybe the old expired certificate)

It could be some kind of security module in the web server, or some kind of firewall, causing this behavior. You could look at your web server error logs to see if you can find evidence that these connections reached your web server and then were rejected for some reason.

You have at least three options here:

(1) Figure out what’s causing incoming connections with invalid SNI names to be dropped and fix that behavior.
(2) Change to -a webroot to change the method used to prove your control over the domain names. This will require you to specify a location (a “webroot directory”) where Certbot can post static files that the web server will serve.
(3) Upgrade to the newest version of Certbot and create a new Let’s Encrypt account. This will use a different method to prove control of the domain, which won’t be affected by this problem.

I can give you more details about how to do (2) or (3) if you decide to pursue either of those.


#3

Thanks for your advice. I will try 2 and 3. If you have more details. They are welcome.


#4

In order to help figure out what commands to use to change the authentication method to webroot, could you post the output of running certbot certificates?


#5

How can I get Cerbot Certificates?


#6

It’s a command to run on your command line.


#7

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