# Telekom filters port 80 - TLS certificate renewal fails **URL:** \ **Category:** đŸ‡©đŸ‡Ș Deutsch (german)\ **Tags:** network, letsencrypt, dns, ncp\ **Created:** [September 14, 2026, 11:50am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320 "2026-09-14T11:50:07Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![luftschiff](https://help.nextcloud.com/letter_avatar/luftschiff/32/5_5575768a8748004e209b776fc1b2916d.png) [@luftschiff](https://help.nextcloud.com/u/luftschiff)\ **Post date:** [September 14, 2026, 11:50am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/1 "2026-09-14T11:50:08Z")
Nextcloudpi running on raspberry pi, with a subdomain of a public domain and dynamic DNS from freedns ([afraid.org](http://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](http://nc.myproject.org): Identifier: [nc.myproject.org](http://nc.myproject.org) Type: connection Detail: xxx.xx.xxx.xxx: Fetching [http://nc.myproject.org/.well-known/acme-challenge/tScKBxxxxxxxxxxxxxxxxxxxxxZ0OL09fg:](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. ---
**Author:** ![ernolf](https://help.nextcloud.com/user_avatar/help.nextcloud.com/ernolf/32/77874_2.png) [@ernolf](https://help.nextcloud.com/u/ernolf)\ **Post date:** [September 14, 2026, 12:50pm UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/2 "2026-09-14T12:50:07Z")
Hi @luftschiff, > [@luftschiff](#): > > so it seems, telekom started filtering requests to my port 80 you haven’t substantiated this claim - which I find completely implausible. Unfortunately, you also failed to fill out the [support template](https://help.nextcloud.com/t/support-template-please-use-this-when-you-request-support/137402) 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 ---
**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\ **Post date:** [September 14, 2026, 7:10pm UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/3 "2026-09-14T19:10:02Z")
1. I would recommend you test if the port is open. Tools exist e.g. [Offene Ports testen - Portfreigabe im Router prĂŒfen](https://www.yougetsignal.com/de/tools/open-ports) 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 ---
**Author:** ![bb77](https://help.nextcloud.com/letter_avatar/bb77/32/5_5575768a8748004e209b776fc1b2916d.png) [@bb77](https://help.nextcloud.com/u/bb77)\ **Post date:** [September 15, 2026, 4:57am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/4 "2026-09-15T04:57:01Z")
One thought that crossed my mind: [afraid.org](http://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? ---
**Author:** ![tflidd](https://help.nextcloud.com/letter_avatar/tflidd/32/5_5575768a8748004e209b776fc1b2916d.png) [@tflidd](https://help.nextcloud.com/u/tflidd)\ **Post date:** [September 15, 2026, 7:03am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/5 "2026-09-15T07:03:47Z")
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. ---
**Author:** ![Mornsgrans](https://help.nextcloud.com/user_avatar/help.nextcloud.com/mornsgrans/32/40386_2.png) [@Mornsgrans](https://help.nextcloud.com/u/Mornsgrans)\ **Post date:** [September 15, 2026, 1:50pm UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/6 "2026-09-15T13:50:54Z")
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. ---
**Author:** ![luftschiff](https://help.nextcloud.com/letter_avatar/luftschiff/32/5_5575768a8748004e209b776fc1b2916d.png) [@luftschiff](https://help.nextcloud.com/u/luftschiff)\ **Post date:** [September 16, 2026, 9:08am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/7 "2026-09-16T09:08:33Z")
i. Testing open ports: on [Offene Ports testen - Portfreigabe im Router prĂŒfen](https://www.yougetsignal.com/de/tools/open-ports) as well as on [canyouseeme.org](http://canyouseeme.org) port 443 is open, but port 80 is filtered (or gives an error on canyouseeme). ii. curl -4 [ifconfig.me](http://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. ---
**Author:** ![luftschiff](https://help.nextcloud.com/letter_avatar/luftschiff/32/5_5575768a8748004e209b776fc1b2916d.png) [@luftschiff](https://help.nextcloud.com/u/luftschiff)\ **Post date:** [September 16, 2026, 9:29am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/8 "2026-09-16T09:29:36Z")
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](http://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) ---
**Author:** ![JimmyKater](https://help.nextcloud.com/user_avatar/help.nextcloud.com/jimmykater/32/4850_2.png) [@JimmyKater](https://help.nextcloud.com/u/JimmyKater)\ **Post date:** [September 16, 2026, 10:00am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/9 "2026-09-16T10:00:56Z")
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 ---
**Author:** ![luftschiff](https://help.nextcloud.com/letter_avatar/luftschiff/32/5_5575768a8748004e209b776fc1b2916d.png) [@luftschiff](https://help.nextcloud.com/u/luftschiff)\ **Post date:** [September 16, 2026, 10:04am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/10 "2026-09-16T10:04:11Z")
Entschuldigung - ich war sprachenverwirrt. ---
**Author:** ![JimmyKater](https://help.nextcloud.com/user_avatar/help.nextcloud.com/jimmykater/32/4850_2.png) [@JimmyKater](https://help.nextcloud.com/u/JimmyKater)\ **Post date:** [September 16, 2026, 10:07am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/11 "2026-09-16T10:07:02Z")
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. ---
**Author:** ![luftschiff](https://help.nextcloud.com/letter_avatar/luftschiff/32/5_5575768a8748004e209b776fc1b2916d.png) [@luftschiff](https://help.nextcloud.com/u/luftschiff)\ **Post date:** [September 16, 2026, 10:25am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/12 "2026-09-16T10:25:46Z")
Kurzes Update: ich habe mit tcpdump gecheckt, was passiert, wenn ich bei [canyouseeme.org](http://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. ---
**Author:** ![Mornsgrans](https://help.nextcloud.com/user_avatar/help.nextcloud.com/mornsgrans/32/40386_2.png) [@Mornsgrans](https://help.nextcloud.com/u/Mornsgrans)\ **Post date:** [September 16, 2026, 11:45am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/13 "2026-09-16T11:45:26Z")
Oder der Software-Firewall deines Servers. ---
**Author:** ![luftschiff](https://help.nextcloud.com/letter_avatar/luftschiff/32/5_5575768a8748004e209b776fc1b2916d.png) [@luftschiff](https://help.nextcloud.com/u/luftschiff)\ **Post date:** [September 16, 2026, 11:51am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/14 "2026-09-16T11:51:10Z")
Wie kann ich das checken? Bisher habe ich: sudo iptables -L -n | grep 80 Leeres Output Und sudo ufw status Status: inactive ---
**Author:** ![luftschiff](https://help.nextcloud.com/letter_avatar/luftschiff/32/5_5575768a8748004e209b776fc1b2916d.png) [@luftschiff](https://help.nextcloud.com/u/luftschiff)\ **Post date:** [September 16, 2026, 12:58pm UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/15 "2026-09-16T12:58:34Z")
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? ---
**Author:** ![Mornsgrans](https://help.nextcloud.com/user_avatar/help.nextcloud.com/mornsgrans/32/40386_2.png) [@Mornsgrans](https://help.nextcloud.com/u/Mornsgrans)\ **Post date:** [September 16, 2026, 1:04pm UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/16 "2026-09-16T13:04:30Z")
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. ---
**Author:** ![luftschiff](https://help.nextcloud.com/letter_avatar/luftschiff/32/5_5575768a8748004e209b776fc1b2916d.png) [@luftschiff](https://help.nextcloud.com/u/luftschiff)\ **Post date:** [September 16, 2026, 4:00pm UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/17 "2026-09-16T16:00:40Z")
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. ---
**Author:** ![ernolf](https://help.nextcloud.com/user_avatar/help.nextcloud.com/ernolf/32/77874_2.png) [@ernolf](https://help.nextcloud.com/u/ernolf)\ **Post date:** [September 16, 2026, 8:57pm UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/18 "2026-09-16T20:57:07Z")
Hi @luftschiff, mit dem tcpdump hast du das Problem eigentlich schon eingegrenzt: > [@luftschiff](#): > > Anfrage an 443 kommt an; Anfrage an 80 nicht. 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: > [@luftschiff](#): > > 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 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: > [@Mornsgrans](#): > > 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. 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: > [@luftschiff](#): > > I have used acme.sh to create certificates with the alpn challenge 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 ---
**Author:** ![luftschiff](https://help.nextcloud.com/letter_avatar/luftschiff/32/5_5575768a8748004e209b776fc1b2916d.png) [@luftschiff](https://help.nextcloud.com/u/luftschiff)\ **Post date:** [September 17, 2026, 7:26am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/19 "2026-09-17T07:26:35Z")
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. ---
**Author:** ![geoW](https://help.nextcloud.com/user_avatar/help.nextcloud.com/geow/32/67506_2.png) [@geoW](https://help.nextcloud.com/u/geoW)\ **Post date:** [September 17, 2026, 8:56am UTC](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320/20 "2026-09-17T08:56:22Z")
> [@luftschiff](#): > > 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. > [@luftschiff](#): > > 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. Also ich dĂ€chte ĂŒber ein update nach. 🙂 [Next page](https://help.nextcloud.com/t/telekom-filters-port-80-tls-certificate-renewal-fails/249320.md?page=2)