Certbot using ipv6 even if disabled

JoeM · December 7, 2021, 2:06pm

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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: gate.altmark-klinikum.de

I ran this command: certbot renew

It produced this output: Timout Error

My web server is (include version): HAProxy

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

My hosting provider, if applicable, is: -

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 1.12.0

Hi, I have a problem that's a bit annoying: certbot uses ipv6 i.e. ::::80 even though ipv6 is disabled on my server. This server only has an ipv4 Address and has no AAAA Record. How can I convince certbot to use ipv4?

Osiris · December 7, 2021, 2:09pm

Please show the entire output, preferably with the -v option of certbot so it's more verbose.

JoeM · December 7, 2021, 2:23pm

Hi, I already renewed by DNS challenge. It was a bit urgent. But I still have the non verbose output in my logs:

Dec 7 14:04:59 aksawedge certbot: Saving debug log to /var/log/letsencrypt/letsencrypt.log
Dec 7 14:04:59 aksawedge certbot:
Dec 7 14:04:59 aksawedge certbot: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dec 7 14:04:59 aksawedge certbot: Processing /etc/letsencrypt/renewal/gate.altmark-klinikum.de.conf
Dec 7 14:04:59 aksawedge certbot: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dec 7 14:04:59 aksawedge certbot: Cert is due for renewal, auto-renewing...
Dec 7 14:04:59 aksawedge certbot: Plugins selected: Authenticator standalone, Installer None
Dec 7 14:05:00 aksawedge certbot: Renewing an existing certificate for gate.altmark-klinikum.de
Dec 7 14:05:00 aksawedge certbot: Performing the following challenges:
Dec 7 14:05:00 aksawedge certbot: http-01 challenge for gate.altmark-klinikum.de
Dec 7 14:05:00 aksawedge certbot: Waiting for verification...
Dec 7 14:05:11 aksawedge certbot: Challenge failed for domain gate.altmark-klinikum.de
Dec 7 14:05:11 aksawedge certbot: http-01 challenge for gate.altmark-klinikum.de
Dec 7 14:05:11 aksawedge certbot: Cleaning up challenges
Dec 7 14:05:11 aksawedge certbot: Failed to renew certificate gate.altmark-klinikum.de with error: Some challenges have failed.
Dec 7 14:05:12 aksawedge certbot:
Dec 7 14:05:12 aksawedge certbot: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dec 7 14:05:12 aksawedge certbot: All renewals failed. The following certificates could not be renewed:
Dec 7 14:05:12 aksawedge certbot: /etc/letsencrypt/live/gate.altmark-klinikum.de/fullchain.pem (failure)
Dec 7 14:05:12 aksawedge certbot: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dec 7 14:05:12 aksawedge certbot: Running post-hook command: /etc/haproxy/cert_LE_renew.sh
Dec 7 14:05:12 aksawedge certbot: 1 renew failure(s), 0 parse failure(s)
Dec 7 14:05:12 aksawedge certbot: IMPORTANT NOTES:
Dec 7 14:05:12 aksawedge certbot: - The following errors were reported by the server:
Dec 7 14:05:12 aksawedge certbot:
Dec 7 14:05:12 aksawedge certbot: Domain: gate.altmark-klinikum.de
Dec 7 14:05:12 aksawedge certbot: Type: connection
Dec 7 14:05:12 aksawedge certbot: Detail: Fetching
Dec 7 14:05:12 aksawedge certbot: http://gate.altmark-klinikum.de/.well-known/acme-challenge/McgnZorl0dSr-61VgqxqXFV2fISyMrkIm1xbLVP39Gg:
Dec 7 14:05:12 aksawedge certbot: Timeout during connect (likely firewall problem)
Dec 7 14:05:12 aksawedge certbot:
Dec 7 14:05:12 aksawedge certbot: To fix these errors, please make sure that your domain name was
Dec 7 14:05:12 aksawedge certbot: entered correctly and the DNS A/AAAA record(s) for that domain
Dec 7 14:05:12 aksawedge certbot: contain(s) the right IP address. Additionally, please check that
Dec 7 14:05:12 aksawedge certbot: your computer has a publicly routable IP address and that no
Dec 7 14:05:12 aksawedge certbot: firewalls are preventing the server from communicating with the
Dec 7 14:05:12 aksawedge certbot: client. If you're using the webroot plugin, you should also verify
Dec 7 14:05:12 aksawedge certbot: that you are serving files from the webroot path you provided.

Osiris · December 7, 2021, 2:34pm

I don't see any reference to IPv6 in that output? Do you have more info about the IPv6 part?

In any case, IPv4 isn't working on port 80 either:

osiris@erazer ~ $ curl -LIv http://gate.altmark-klinikum.de/.well-known/acme-challenge/McgnZorl0dSr-61VgqxqXFV2fISyMrkIm1xbLVP39Gg
*   Trying 45.13.21.13:80...
^C
osiris@erazer ~ $

(Hit Ctrl-C as it took me too long, would have timed out..)

JoeM · December 7, 2021, 2:49pm

There is usually no service running on port 80. Certbot only starts a temporary service on port 80 which I could observe with "watch -n 1 netstat -tulpen".
that showed tcp6 [...] :::80 :::* [...] PID/python

Osiris · December 7, 2021, 3:38pm

Usually you'd get an immediate "Connection refused" error if there isn't anything listening on a port and it isn't firewalled, not a timeout.

Also, unless /proc/sys/net/ipv6/bindv6only is set to 1, the socket listening on :::80 is also accepting IPv4 connections, so nothing strange there. See linux - Semantics of :: and 0.0.0.0 in dual-stack OSes - Server Fault for more info. However, even if bindv6only is set, certbot will correctly listen on IPv4 and on IPv6, as demonstrated by:

server ~ # cat /proc/sys/net/ipv6/bindv6only
0
server ~ # netstat -tulpen | grep python
tcp6       0      0 :::80                   :::*                    LISTEN      0          17943545   23547/python3.9    
server ~ # echo "1" > /proc/sys/net/ipv6/bindv6only
server ~ # cat /proc/sys/net/ipv6/bindv6only
1
server ~ # netstat -tulpen | grep python
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          17947075   23578/python3.9     
tcp6       0      0 :::80                   :::*                    LISTEN      0          17947074   23578/python3.9     
server ~ #

(In a different screen window I used certbot certonly --staging --standalone --debug-challenges -d example.com to have certbot listen on port 80..)

So no problem with certbot nor Let's Encrypt if you'd ask me. Highly likely this is a firewall and/or router issue.

JoeM · December 7, 2021, 4:54pm

Thanks for the quick help! Just found the exact same info. Was a bit confused by other services just having a tcpv4 port open. So i'm going to talk to the firewall guys tomorrow.

rg305 · December 8, 2021, 2:10am

Sounds like there is some IPv6 left in there somewhere...
But that's nothing to worry about.
Most things that show bound to IPv6, bind to both IPv4 & IPv6 [but only show one].

system · January 7, 2022, 2:10am

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

Topic		Replies	Views
Certbot trying a challenge to old IPv6 instead of new IPv4 Help	10	1076	August 15, 2021
Certbot issual failure Help	6	574	October 21, 2023
Problem with Certbot renew Help	59	2533	November 30, 2020
IPv6 not working on the staging us-west-2 VA Help	4	683	February 1, 2020
Some challenges have failed Help	11	713	May 2, 2021

Certbot using ipv6 even if disabled

Related topics