Certificate renew does not work (standalone)

Help
1

Hi there,

for my life I just can’t find the error. The machine in question does not run a webservice, so port 80 (and 443) are both free. From the debug-log I can see it is bound to the IPv6 address, but I have no AAAA record set (only CNAME to dyndns-adress -> to my IP).

When I bind some other program to port 80 on that machine (eg via nc), the portforward clearly works.

I have a debug-log of the successfull creation of the certificates (approx 2 months ago) and a debug log of a lot of failed tries to renew the certificate, if this helps.

Any help / hint is appreciated.

My domain is:
unifi.seconet.de

I ran this command:
certbot renew

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/unifi.seconet.de.conf

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for unifi.seconet.de
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (unifi.seconet.de) from /etc/letsencrypt/renewal/unifi.seconet.de.conf produced an unexpected error: Failed authorization procedure. unifi.seconet.de (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://unifi.seconet.de/.well-known/acme-challenge/G-Rvam5D_D9WSBgPTFZ1oz2rY2igmFkRSsfp973ULEw: Timeout during connect (likely firewall problem). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/unifi.seconet.de/fullchain.pem (failure)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/unifi.seconet.de/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: unifi.seconet.de
    Type: connection
    Detail: Fetching
    http://unifi.seconet.de/.well-known/acme-challenge/G-Rvam5D_D9WSBgPTFZ1oz2rY2igmFkRSsfp973ULEw:
    Timeout during connect (likely firewall problem)

    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):
none (standalone)

The operating system my web server runs on is (include version):
Debian Stretch 9.11

My hosting provider, if applicable, is:
n/a

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 0.28.0

2

Have you verified that it works from outside of your NAT?

If the port forward was working, I would usually expect a "Connection refused" (RST,ACK) error, indicating nothing is listening. Instead, no response comes at all.

I don't think that your ISP is blocking any ports, based on other hosts in your network.

Can you try listen on port 80 with something more permanent, and we can check again?

3

Sure, I just spun up nginx to listen on that port - you should be greeted with the typical “welcome to nginx” page.

Once we verified that port forwarding is working, I will decomission nginx again.

Thanks for taking this one up.

Best Regards,
Tom

4

Great. Can’t access it though - same network timeout.

Tested from multiple locations.

5

Right on top of it. Currenty experiencing an isuue with my dyndns setup - will come back to you shortly. (slap on the back of my head for not checking this one earlier)

6

First of all: Thanks for pushing me into the right direction - renewal now worked flawlessly like the last time.

Root cause: Stupidity.
More detailed: Typo in dyndns-setup while changing gear. Pretty sure I checked IP-addresses when starting yesterday morning, but during the course of fixing thing I seem to have lost track of that one and took the correct dyndns for granted.

Sorry for probably wasting your time / efforts. Thanks again for your support.

Tom

7

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