I have been running my RaspberryPi with a NextcloudPi installation for several years by now.
The domain I use to contact the server from the outside points via A- and AAAA-Record to a vServer which tunnels ports 80 and 443 using 6tunnel onto dyndns.schiebockner.de. This domain in turn points via NS-Record to n1, ns2 and ns3.dynv6.com. This DynDNS service gets updated by my router at home.
This setup has been running fine for 2 months now when I added the vServer to make my server behind my IPv6 connection at home reachable from IPv4 as well as IPv6.
Today my TLS certificate expired and I noticed that the update of the certificate is not working any more. I am assuming this is case since the vServer was added to the chain.
Well, your server (or whatever's listening on the IPv6 address of your server) is refusing connections on your IPv6 address. Since renewal would ordinarily have been done a month ago, any relevant change you made would have been before that time.
But why can I reach the Nextcloud web interface and why can all my Nextcloud clients connect to my server? If the server was refusing connections, that would not be working, right?
The estimated time you are giving is one more argument for the added vServer to be the issue. Is there any reason why a port forwarding through 6tunnel should cause an issue for certificate renewal?
Thanks for mentioning Let's Dabug @linkp. I did not know this service yet.
You are right, the first section AAAANotWorking is missing in the TLS-ALPN-01 results.
As far as I can see, the second section IssueFromLetsEncrypt is the same for both tests.
Is that not normal?
Both ports (80 and 443) are handled equally by the domains, the vServer and my router/firewall.
But I will check this point again.
Nope, can not find any different settings for ports 80 and 443 or IPv4 and IPv6.
1st domain contains correct A- and AAAA-Record of vServer.
2nd domain contains NS-Record of dynv6.
And this is from my routers configuration.
Please excuse the German UI on the last one. The headers read from left to right:
Device/Name, IP Address, Clearance, external Port IPv4, external Port IPv6
Are those testing connections from the public internet? Or from your local network.
I'm not familiar with 6tunnel but if that's the recent addition to your mix you might try asking on their forum.
From my own test server I also fail to reach you via IPv6 just like Let's Debug and Let's Encrypt. You need to trace the incoming request using IPv6 from your first component to the responding server. Something in that path is refusing the IPv6 connection.
curl -i4 http://cloud.schiebockner.de
HTTP/1.1 302 Found
Date: Mon, 15 Sep 2025 22:08:00 GMT
Server: Apache
curl -i6 http://cloud.schiebockner.de
curl: (7) Failed to connect to cloud.schiebockner.de port 80 after 124 ms:
Connection refused
I temporarily took the vServer out of the chain to see if that would fix the problem. And it did.
The certbot output using the setup cloud.schiebockner.de -> DynDNS (schiebockner.dynv6.net) -> RaspberryPi
Changing back to my initial setup including the vServer cloud.schiebockner.de -> vServer -> DynDNS (schiebockner.dynv6.net) -> RaspberryPi
I get the same error as in my original post:
pi@raspi-nextcloud:~ $ sudo certbot renew --dry-run -v
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/cloud.schiebockner.de-0001.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Simulating renewal of an existing certificate for cloud.schiebockner.de
Performing the following challenges:
http-01 challenge for cloud.schiebockner.de
Using the webroot path /var/www/nextcloud for all unmatched domains.
Waiting for verification...
Challenge failed for domain cloud.schiebockner.de
http-01 challenge for cloud.schiebockner.de
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: cloud.schiebockner.de
Type: connection
Detail: 2a01:239:26a:8400::1: Fetching https://cloud.schiebockner.de/.well-known/acme-challenge/xbDEQgR4IYFhw2rGu0XQLUZw3uar9WNGdtm04dK8tfw: Connection refused
Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
Cleaning up challenges
Failed to renew certificate cloud.schiebockner.de-0001 with error: Some challenges have failed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/cloud.schiebockner.de-0001/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
So the vServer is clearly causing the issue here.
Nevertheless, I would like to keep using it, since it enables me to access my server at home through IPv4 as well as through IPv6.
By the way, I used the test setup to update the certificate for now, so you can verify that my Nextcloud interface is accessible through cloud.schiebockner.de.
So it seems like only certbot is affected by the vServer.
I still cannot connect to that domain using IPv6. I still get this
Can you explain more what you mean by that? It looks like inbound requests using IPv6 to your domain fail generally. Nothing unique to the URL that Let's Encrypt sends to you.
