Telekom filters port 80 - TLS certificate renewal fails

🌐 International support đŸ‡©đŸ‡Ș Deutsch (german)
, , ,
1

Nextcloudpi running on raspberry pi, with a subdomain of a public domain and dynamic DNS from freedns (afraid.org).
Everything worked incredibly well (thanks nextcloud!) until, so it seems, telekom started filtering requests to my port 80. As a consequence, automatic TLS-certificate renewal (with certbot, and http-01) fails and my system is broken:(
My research failed to find a solution other than buying my own domain.
Has anyone had the same issues, and possibly found other solutions?
Would be most interested and grateful.

As requested, some context:
Nextcloud Server version: 28.0.14.1
Operating system and version: Debian GNU/Linux 11 (bullseye)
Web server and version: Apache/2.4.67 (Debian)
Reverse proxy and version: no reverse proxy
PHP version (e.g, 8.3): 8.3.33
Is this the first time you’ve seen this error? Yes
When did this problem seem to first start? 2025
Installation method: NextcloudPi image, etched on SD card
Are you using Cloudflare, mod_security, or similar? Not that I am aware of.

I have a residential internet connection provided by Telekom, in Germany.

Error message from trying to (test) run renewal of the certificate with
sudo certbot renew -v --dry-run --cert-name nc.myproject.org:

Identifier: nc.myproject.org
Type: connection
Detail: xxx.xx.xxx.xxx: Fetching http://nc.myproject.org/.well-known/acme-challenge/tScKBxxxxxxxxxxxxxxxxxxxxxZ0OL09fg: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed identifiers serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

2

Hi @luftschiff,

you haven’t substantiated this claim - which I find completely implausible. Unfortunately, you also failed to fill out the support template or provide key details that might be relevant to resolving your issue. For instance, you mention “Telekom” but don’t specify which country you are in. I am a customer of “Telekom” myself - specifically in Germany - and no ports are blocked there. That would be truly outrageous; if that were actually the case, you really ought to lodge a complaint with that specific “Telekom” of yours.
My initial suspicion would fall on your router. Which router are you using? How are the port forwarding rules set up? Do you happen to have IPv6 enabled? If so, try using strictly IPv4—meaning, disable IPv6 entirely on your router.
As you can see, I’m essentially taking shots in the dark here, but what else can I do when you make an unsubstantiated claim without providing any further information?
No offense intended - I’m certainly willing to believe what you’re saying, but (not only) I’d need more details, such as how you arrived at that conclusion.
At the very least, there is an issue where automatic TLS certificate renewal isn’t working any more.
What do the log files say?

ernolf

3
  1. I would recommend you test if the port is open. Tools exist e.g. Offene Ports testen - Portfreigabe im Router prĂŒfen to see if the connection works.
  2. if it comes out the port is closed buying a domain would not help immediately - certbot would still fail (but you could obtain a wildcard cert)
  3. aside on well-known HTTP-01 there is a more modern TLS-01 ACME challenge which runs completely over TLS and doesn’t require port 80
4

One thought that crossed my mind: afraid.org expects you to log in to your free account every so often (I don’t know the exact frequency off the top of my head); otherwise, they’ll disable your DynDNS name. Have you done that and checked whether your DynDNS name is still active?

5

Before changing the setup and everything, if such port locking is really put in place, I’d try to confirm first with my ISP. Perhaps it is just a new default setting that you can change. Or it is not the ISP itself, it could be a new firmware upgrade of your router, it depends at which level it is filtered.

6

If there is a remote access to the router enabled, the port 80 might be blocked resp. cannot be forwarded to your NC instance. In that case the port 443 also should be reserved for remote access.

7

i. Testing open ports: on Offene Ports testen - Portfreigabe im Router prĂŒfen as well as on canyouseeme.org port 443 is open, but port 80 is filtered (or gives an error on canyouseeme).

ii. curl -4 ifconfig.me and dig +short give back the same IP address. If I understand this correctly, this shows that dynamic DNS is working.

iii. In Telekom Speedport Smart 3 router I have exactly two port forwarding rules, port 80 → port 80 of my Raspberry Pi, and Port 443 → Port 443. According to ls -la <../../archive/ this has worked for 10 or 11 generations before failing a few months back.

iv. TLS-01 ACME: will check. I had researched various challenge types, and the alternatives all seemed infeasible with my setup, for various reasons. E.g. because freedns uses captcha and wouldn’t let me upload .txt files automatically. But my experience with that is very limited and I will research this some more.

v. Just off the phone with telekom who said that they would not filter traffic to any port on their end. They did say that they run remote software updates for the routers, so will try to check there whether anything has changed/is off.

8

Tail of the log file (/var/log/letsencrypt/letsencrypt.log):

2026-09-16 09:40:22,484:INFO:certbot._internal.auth_handler:Cleaning up challenges
2026-09-16 09:40:22,485:DEBUG:certbot._internal.plugins.webroot:Removing /var/www/nextcloud/.well-known/acme-challenge/tScKBFBJwTypFsF5p23hImkxy43Q0BjcC3XZ0OL09fg
2026-09-16 09:40:22,486:DEBUG:certbot._internal.plugins.webroot:All challenges cleaned up
2026-09-16 09:40:22,487:ERROR:certbot._internal.renewal:Failed to renew certificate nc.myproject.org with error: Some challenges have failed.
2026-09-16 09:40:22,499:DEBUG:certbot._internal.renewal:Traceback was:
Traceback (most recent call last):
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/renewal.py”, line 715, in handle_renewal_request
main.renew_cert(lineage_config, plugins, renewal_candidate)
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/main.py”, line 1551, in renew_cert
renewed_lineage = _get_and_save_cert(le_client, config, lineage=lineage)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/main.py”, line 131, in _get_and_save_cert
renewal.renew_cert(config, sans, le_client, lineage)
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/renewal.py”, line 565, in renew_cert
new_cert, new_chain, new_key, _ = le_client.obtain_certificate(sans, new_key)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/client.py”, line 434, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/client.py”, line 512, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/auth_handler.py”, line 104, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, max_time_mins, best_effort)
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/auth_handler.py”, line 208, in _poll_authorizations
raise errors.AuthorizationError(‘Some challenges have failed.’)
certbot.errors.AuthorizationError: Some challenges have failed.

2026-09-16 09:40:22,506:DEBUG:certbot._internal.display.obj:Notifying user:

2026-09-16 09:40:22,508:ERROR:certbot._internal.renewal:All simulated renewals failed. The following certificates could not be renewed:
2026-09-16 09:40:22,509:ERROR:certbot._internal.renewal: /etc/letsencrypt/live/nc.myproject.org/fullchain.pem (failure)
2026-09-16 09:40:22,510:DEBUG:certbot._internal.display.obj:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2026-09-16 09:40:22,510:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File “/snap/certbot/5892/bin/certbot”, line 6, in
sys.exit(main())
^^^^^^
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/main.py”, line 18, in main
return internal_main.main(cli_args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/main.py”, line 1889, in main
return config.func(config, plugins)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/main.py”, line 1639, in renew
renewal.handle_renewal_request(config)
File “/snap/certbot/5892/lib/python3.12/site-packages/certbot/_internal/renewal.py”, line 745, in handle_renewal_request
raise errors.Error(
certbot.errors.Error: 1 renew failure(s), 0 parse failure(s)
2026-09-16 09:40:22,515:ERROR:certbot._internal.log:1 renew failure(s), 0 parse failure(s)

9

hier wird jetzt offenbar deutsch gesprochen (außerdem ist “Telekom” wohl ein deutschsprachiger Indikator
 darum habe ich alles nach “deutsch” verschoben. also bitte gerne deutsch weiterschreiben

10

Entschuldigung - ich war sprachenverwirrt.

11

das ist ist diesem Fall nicht schlimm, nehme ich an.
ich bin guter Dinge, dass “Telekom” als Provider - Probleme in den allermeisten FĂ€llen nur deutschsprachige Benutzer betreffen bzw nur Benutzer aus D.

12

Kurzes Update:
ich habe mit tcpdump gecheckt, was passiert, wenn ich bei canyouseeme.org meine Ports checke. Anfrage an 443 kommt an; Anfrage an 80 nicht.
Daraus wĂŒrde ich schließen, dass das Problem am Router liegen muss.

13

Oder der Software-Firewall deines Servers.

14

Wie kann ich das checken?
Bisher habe ich:

sudo iptables -L -n | grep 80
Leeres Output

Und sudo ufw status
Status: inactive

15

Ich verstehe den Punkt aber auch nicht. Selbst wenn mein Server (mir unbekannterweise) eine Firewall haben sollte, die Pakete fĂŒr Port 80 blockiert, dann sollte tcpdump die vor der Firewall empfangen, oder liege ich da falsch?

16

Ok, dann ist diese schon mal außen vor.
PrĂŒfe bitte auch die Logfiles Deines Webservers
/var/log/apache2/access_log
bzw.
/var/log/nginx/access_log
oder Ă€hnlich (achte auf das Änderungsdatum der Log-Dateien.
In den Logs nachsehen, ob dort Anfragen von Letsencrypt möglicherweise “ins Leere” gegangen sind.

Ich habe in der Vergangenheit die Erfahrung gemacht, dass mindestens beim ersten Erteilen eines Letsencrypt-Zertifikates der Webserver-Dienst (Apache/Nginx) beendet sein muss, weil Letsencrypt auf dem Rechner einen eigenen Webserverdienst zur Validierung startet. - LĂ€uft Apache/Nginx, blockieren diese den Port 80 fĂŒr den Letsencrypt Webserver-Dienst.

17

I am really not sure what to make of this, and I am a bit surprised that there aren’t more cases like that online.
Since I have not been making any progress, really, I try to work around this. So I have used acme.sh to create certificates with the alpn challenge.
That took a bit of work to get running but seems to have worked. Now I still need to get the certificates in the right place. Fingers crossed that work-around will bring my nc back to life


Update:

Put all the files in place manually, which took a bit more work, but at least it did work.
I suppose I could now write myself a script for automating this process, except that, for acme.sh to work and create the certificates, I had to point traffic coming in on port 443 to some other port on my raspberry.
In summary: yay, it works. But meh, it seems a really fragile workaround.

18

Hi @luftschiff,

mit dem tcpdump hast du das Problem eigentlich schon eingegrenzt:

Wenn tcpdump auf dem Pi fĂŒr Port 80 gar nichts sieht, ist das Paket nie beim Pi angekommen. tcpdump liest vor netfilter mit, eine Firewall auf dem Pi kann das also nicht sein, da liegst du in Beitrag 15 richtig:

Damit fÀllt einiges weg:

  • Telekom-Netz: sie sagen, sie filtern nicht, und 443 kommt auf derselben öffentlichen IPv4 ja auch durch.
  • DynDNS: curl -4 ifconfig.me und dig liefern dieselbe IP, und 443 landet tatsĂ€chlich auf dem Pi.
  • IPv6: Let’s Encrypt meldet im Fehler eine IPv4-Adresse, canyouseeme testet ebenfalls IPv4.
  • Firewall auf dem Pi: siehe oben.

Übrig bleibt der Speedport. Beide Regeln zeigen auf denselben Pi, 443 wird weitergeleitet, 80 nicht. Der Router verwirft Port 80 also selbst oder benutzt ihn fĂŒr etwas anderes. Dass die Telekom Firmware-Updates auf die Router spielt und es seit ein paar Monaten nicht mehr geht, wĂŒrde dazu passen. Ich wĂŒrde am Speedport so vorgehen:

  1. Die Regel fĂŒr Port 80 löschen, den Router neu starten und die Regel neu anlegen.
  2. Nachsehen, ob am Speedport ein Fernzugriff oder ein anderer Dienst aktiv ist, der Port 80 selbst belegt, und ihn testweise abschalten.
  3. Von außen testen, zum Beispiel mit dem Handy im Mobilfunknetz (WLAN aus), nicht aus dem eigenen LAN, und dabei tcpdump auf dem Pi mitlaufen lassen.

Zu Beitrag 16:

Apache stoppen muss man nur beim --standalone-Plugin von certbot. Dein Log zeigt aber plugins.webroot. Dabei legt certbot die Datei unter /var/www/nextcloud/.well-known/acme-challenge/ ab, und Apache liefert sie aus. Apache muss dafĂŒr also laufen.

Zu deinem Workaround:

Wenn du bei TLS-ALPN mit acme.sh bleiben willst, lĂ€sst sich das automatisieren, ohne 443 dauerhaft umzubiegen. acme.sh kann ĂŒber --pre-hook Apache kurz stoppen und ĂŒber --post-hook wieder starten. Das kostet alle 60 Tage ein paar Sekunden Ausfall. Mit acme.sh --install-cert und --reloadcmd legt es die Zertifikate außerdem selbst an die richtige Stelle, das Kopieren von Hand fĂ€llt weg.

Sauberer bleibt aber, Port 80 am Router wieder zum Laufen zu bringen. Dann funktioniert auch die normale Erneuerung von NextcloudPi wieder, ohne Sonderweg.

h.t.h.

ernolf

19

Alle 60 Tage ein paar Sekunden Ausfall ist fĂŒr meine Anwendung ĂŒberhaupt kein Problem. Werde versuchen, die Lösung mit acme.sh zu automatisieren. Das ursprĂŒngliche Problem ist auf den Router eingegrenzt - allerdings habe ich schon alle Einstellungen durchsucht, so gut ich konnte, und bin mir nicht sicher, ob ich da noch weiterkomme.
Die einzige Sache, die ich noch ausprobieren wollte, ist die automatischen Firmware Updates auszuschalten - keine Ahnung, ob es plausibel ist, dass die den Port 80 fĂŒr sich beanspruchen.

20

Also ich dĂ€chte ĂŒber ein update nach. :slightly_smiling_face: