Pi-hole Web UI Unreachable After a Failed TLS Certificate Auto-Renewal

I noticed that the Web UI of the Pi-hole I run at home (http://127.0.0.1:8053/admin) had become completely unreachable.
All I got back was Connection reset by peer, and neither the browser nor curl could see anything.
DNS resolution (port 53) was still working fine, so there was no real damage.
As far as docker ps went the container was shown as healthy, so I had not been worried, but when I looked into it I found that the problem itself went back six days, to 2026-08-01.

Only the Web UI was dead while the container reported healthy

The first things I suspected were the port mapping on the host or a firewall problem.
I decided to narrow it down from the top.

docker ps -a

The container was shown as Up and healthy, so at first glance it looked normal.
Only later did I realise that this health check only looks at DNS responses and knows nothing about whether the web server is alive.

dig @127.0.0.1 example.com

DNS resolution went through without a problem, so I could at least conclude that anything around port 53 was unrelated.

curl http://127.0.0.1:8053/admin/

This one failed with Connection reset by peer. Only the connection from the host to the Web UI was dead.
To work out whether the port mapping was to blame, I also hit it directly from inside the container.

docker exec pihole curl 127.0.0.1:80

It was unreachable from inside the container as well. That killed the hypothesis that “the port mapping on the host is broken” and showed that the web server process inside the container itself was not responding.
Sure enough, when I checked the pihole-FTL process inside the container, the web server thread that should have been there did not exist.

Identifying the cause from the logs

The process state alone was not getting me anywhere, so I went back through docker logs looking for web server related entries.

docker logs pihole | grep -i webserver

At 2026-08-01 15:55, at the point where the certificate was automatically renewed, this error had been left behind.

WARNING: No web server ports configured!
ERROR: Start of webserver failed! Web interface will not be available!

That made everything fit together. By design, Pi-hole automatically regenerates its self-signed TLS certificate every 47 days, and once it is two days from expiry it regenerates the certificate and restarts the web server.
This environment does not use HTTPS and runs on HTTP only, but the processing involved in initialising the TLS port (443) failed, and the startup of the whole web server, including HTTP (80), failed along with it. The DNS function runs in a separate thread from the web server, so it was not affected.

Quick fix: restart the container

Once the cause was clear, the quick fix was simple.

docker restart pihole

The restart brought the web server up normally and the Web UI came back (I confirmed an HTTP 302).

Permanent fix: disable TLS certificate auto-renewal itself

Since I am not running HTTPS in the first place, I decided that the TLS certificate auto-renewal feature itself was unnecessary. Add the following to the pihole service in docker-compose.yml.

environment:
  ...
  FTLCONF_webserver_port: "80o,[::]:80o"        # stop listening on the 443 (TLS) port
  FTLCONF_webserver_tls_validity: "0"           # disable automatic certificate regeneration

• I removed 443os / [::]:443os from webserver_port so that the web server does not try to open a TLS socket at startup
• With webserver_tls_validity: 0 I stopped the automatic regeneration that kicks in as the certificate nears expiry (according to the comment in the config file, specifying 0 days generates a fixed certificate valid for about 30 years and never renews it afterwards)

I applied it with the following command.

cd /home/hoge-user/docker/dnscrypt-pihole && docker-compose up -d pihole

Note that this host does not have the docker compose plugin installed, so docker-compose (standalone, v5.4.0) has to be used.

After applying it, I confirmed that port = "80o,[::]:80o" in the [webserver] section of /etc/pihole/pihole.toml and validity = 0 under [webserver.tls] had been picked up, and that both the Web UI (302 response) and DNS resolution were working normally.

What the o and s flags mean

The o and s in the default value 80o,443os,[::]:80o,[::]:443os are per-port flags interpreted by the web server engine (CivetWeb).

For reference there is also an r (redirect) flag, which redirects HTTP traffic on that port to the first configured SSL port. I did not use it this time.

With that in mind, the default 80o,443os,... means “do not error out if port 80 (HTTP) cannot be opened / do not error out if port 443 (HTTPS) cannot be opened either” (443os is the combination of o + s). After this change it is 80o,[::]:80o, with the port 443 entry removed entirely. As a result Pi-hole no longer opens a TLS socket and does not generate or auto-renew certificates at all. I left o on port 80, but in practice it is assumed that it always binds.

Also note that ./etc-pihole_data/tls.pem will no longer be renewed automatically, so if you go back to HTTPS in the future you will need to revert the settings or manage the certificate by hand.

Summary

The healthy state in docker ps only watches whether DNS is alive, so it is easy to mistake things for “normal” even when only the Web UI is dead. If you run into the same symptoms, check the web server startup log with docker logs pihole | grep -i webserver as early as you can.

In this setup (personal, internal use on a closed network such as a home or an office) I deliberately run over HTTP and also keep access to the Web UI restricted. For use inside a LAN or another trusted boundary, non-HTTPS is enough to satisfy the security requirements.

If you later need to expose it externally or reach it over the internet, that is the point to consider adding HTTPS and revisiting how certificates are handled (bringing back auto-renewal or managing them manually).

See also