Pi-hole’s web interface can be secured with HTTPS, but it’s not enabled by default and requires manual configuration.
Let’s see Pi-hole serving its admin interface over HTTPS. Imagine you’ve just installed Pi-hole and want to access its dashboard. By default, you’d go to http://<pi-hole-ip>/admin.
curl -I http://192.168.1.100/admin
This would show you a 200 OK with Content-Type: text/html. Now, after configuring HTTPS, you’d access it via https://<pi-hole-ip>/admin.
curl -I https://192.168.1.100/admin
This should also return a 200 OK, but this time the connection is encrypted.
Pi-hole uses lighttpd as its web server. To enable HTTPS, we need to configure lighttpd to listen on port 443 and use SSL certificates. This involves generating or obtaining SSL certificates and then telling lighttpd where to find them and how to use them.
The primary configuration file for lighttpd in Pi-hole is located at /etc/lighttpd/lighttpd.conf. You’ll be making changes within this file.
First, you need an SSL certificate and a private key. For testing, you can generate a self-signed certificate. This won’t be trusted by your browser, so you’ll get a warning, but it demonstrates the HTTPS functionality.
To generate a self-signed certificate and key, use OpenSSL:
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/lighttpd/server.key -out /etc/lighttpd/server.crt
You’ll be prompted for information like Country Name, State, Organization Name, etc. For the Common Name, enter your Pi-hole’s IP address or hostname (e.g., 192.168.1.100 or pi.hole).
This command creates two files:
/etc/lighttpd/server.key: Your private key. Keep this secure!/etc/lighttpd/server.crt: Your public certificate.
Next, edit the lighttpd.conf file:
sudo nano /etc/lighttpd/lighttpd.conf
You need to uncomment and modify a section related to SSL. Look for lines similar to this:
#ssl.engine = "enable"
#ssl.pemfile = "/etc/lighttpd/server.pem"
Uncomment them and change ssl.pemfile to point to your generated key and certificate. Since we generated them separately, we need to tell lighttpd about both:
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/server.key"
ssl.certfile = "/etc/lighttpd/server.crt"
You also need to ensure lighttpd is listening on port 443. Look for the server.port directive. If it’s set to 80, you’ll need to add a separate listener for 443 or modify it if you want to exclusively use HTTPS. A common approach is to have separate configurations for HTTP and HTTPS. You might see something like this:
server.port = 80
To add HTTPS, you can add another port directive or use conditional logic. A simpler way for Pi-hole is to ensure the SSL configuration is active. The default Pi-hole lighttpd.conf often has a dedicated section for SSL that just needs enabling. Find the ssl. block and ensure it’s configured as above.
After saving the changes to lighttpd.conf, you need to restart the lighttpd service for them to take effect:
sudo systemctl restart lighttpd
Now, try accessing your Pi-hole interface using https://<pi-hole-ip>/admin. Your browser will likely show a security warning because the certificate is self-signed. You’ll need to accept the risk to proceed.
If you want a trusted certificate without browser warnings, you should obtain one from a Certificate Authority (CA). Let’s Encrypt is a popular free option. You can use certbot to automate this process.
First, install certbot and its lighttpd plugin:
sudo apt update
sudo apt install certbot python3-certbot-lighttpd -y
Then, run certbot to obtain and install a certificate for your domain (e.g., pi.hole):
sudo certbot --lighttpd -d pi.hole
certbot will automatically modify your lighttpd.conf to use the Let’s Encrypt certificates and set up automatic renewal. It will also likely configure a redirect from HTTP to HTTPS.
The critical part that often trips people up with self-signed certificates is that browsers are designed to warn users about untrusted sources. This isn’t a Pi-hole failure, but a fundamental security feature of the web. For internal networks, self-signed certificates are acceptable for encryption, but not for establishing trust.
Once HTTPS is working, the next thing you might encounter is needing to manage the certificates, especially when they expire or if you switch to a different domain name.