Self signed certificate for PiHole v6 does not work after Bookworm upgrade

Troubleshooting
1

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=11
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
bookworm 1
Linux DietPi 6.1.21-v7+ #1642 SMP Mon Apr 3 17:20:52 BST 2023 armv7l GNU/Linux
armhf
RPi 3 Model B (armv7l)

Additional Information (if applicable)

  • PiHole Core v6.0.5, FTL v6.0.4, Web interface v6.0.2
  • Software reinstalled via bookworm upgrade script

Steps to reproduce

  1. Run Bookworm upgrade script
  2. Select yes to run migrations of software
  3. Access PiHole admin https://pi.hole:8089/admin

Expected behaviour

  • Access dashboard without error

Actual behaviour

  • The browser returns `An error occurred during a connection to pi.hole:8089. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG`

Extra details

  • Prior to upgrade, I was running Bullseye and PiHole v6 and accessing via https://pi.hole/admin without error using the native self signed certificate
  • After the Bookworm upgrade, I noted the reinstallation script had change the port to 8089
  • I tried to regenerate the certificate by running sudo rm /etc/pihole/tls* && sudo service pihole-FTL restart as per PiHole documentation TLS/SSL - Pi-hole documentation but no certificate was regenerated
2

Ok, I fixed the problem by going back to PiHole v6 defaults for the webserver port 80o,443os,[::]:80o,[::]:443os

So the issue I guess is that Dietpi doesn’t specify a secure port, only 8089. Will Dietpi specify a secure port in future?

3

Yes, by default we only use http on port 8089. We do this to avoid port conflicts with other applications that users (might) install on their systems. How to use https, we are yet to add in our online documents as an optional setting. However, we will probably not use the default web server ports 80/443 as these are normally used by Apache or Nginx.

4

Thanks for confirming about https in future.

Whilst the upgrade to Bookworm largely went smoothly, I had an issue with Unbound not working properly afterwards. Every initial forwarded DNS query would fail (or not respond), but subsequent requests would succeed. I fixed this by uninstalling and reinstalling. Perhaps there is still some config from Bulleyes that didn’t get migrated properly to Bookworm.

I currently have the following warning in the log. I’m not sure if this is normal, can someone check their logs?

Mar 12 11:49:40 DietPi systemd[1]: Starting unbound.service - Unbound DNS server...
Mar 12 11:49:40 DietPi unbound-helper[13456]: Updating /var/lib/unbound/root.key from /usr/share/dns/root.key
Mar 12 11:49:40 DietPi unbound[13461]: [13461:0] warning: subnetcache: serve-expired is set but not working for data originating from the subnet module cache.
Mar 12 11:49:40 DietPi unbound[13461]: [13461:0] warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache.
Mar 12 11:49:40 DietPi unbound[13461]: [13461:0] info: start of service (unbound 1.17.1).
Mar 12 11:49:40 DietPi systemd[1]: Started unbound.service - Unbound DNS server.
5

There is actually no configuration that needs to be migrated. So it must have been something else. Which upstream DNS server is used in the DietPi network configuration?

The warning messages should be ok

6

Sorry, I don’t understand the question. How do I find out?

7

Just researched the same warnings. See the following in particular the last posting:

https://www.reddit.com/r/pihole/comments/11xb7pt/unbound_warning_subnetcache_prefetch_and/

8

Unbound does not use upstream DNS servers. Instead it goes directly to the top level domain server as I understand it from the dietpi unbound software page.

9

My question was not related to the unbound upstream DNS configuration. Rather, I am interested in the DietPi network settings and which DNS has been configured for the operating system itself.

cat /etc/resolv.conf
10

It’s cloudflare by the looks of it.

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 1.1.1.1
nameserver 1.0.0.1
11

It looks as if the file is managed via resolvconf. Are you using DHCP or STATIC IP for this device? For a DNS server like PiHole, AGH or Unbound I would recommend STATIC IP.

12

It’s a static IP and I have PiHole as the DHCP server for the network. I’ve been running this way for many years. Is there any checks that I could do?

EDIT: Just checked in dietpi-config and it is showing as STATIC

13

In this case i recommend to remove resolvconf as it is not needed. If I’m not mistaken, it has been installed by PiHole years back but should not be needed.

14

What is the best way to remove as I really have no idea? Is it the same as described in unbound - Pi-hole documentation ?

15

Just use the normal Debian apt command to remove the resolvconf package

apt purge resolvconf

Then check /etc/resolv.conf again to see which DNS servers are now entered.

16

Ok, after the purge it still shows the same nameserver entries but without the comments. Is this correct?


nameserver 1.1.1.1
nameserver 1.0.0.1
17

Yes should be the one you selected from dietpi-config. Right?

18

Yes, but now I can’t remember if I set that manually or it was the default from long time ago.

Under what circumstances will this DNS setting be used and why option 3 (localhost) is not recommended?

1.1.1.1 1.0.0.1               : Your current DNS server                                                │ 
│               192.168.1.1                   : Use local router as DNS server (recommended)                           │ 
│               127.0.0.1                     : Use local Pi-hole/AdGuard Home/Unbound (not recommended)               │ 
│               Custom                        : Manually enter your DNS server
19

This local setting is only used by the operating system itself. It has no effect on the use of PiHole, AGH or Unbound.

We do not recommend using locahost because it can cause problems in certain situations.

For example if the OS would use PiHole: What happens if PiHole stops running due to an error? Then the OS would no longer be able to resolve DNS requests. You would not be able to install packages or perform similar repairs and would then have to adjust the DNS settings again.

1 Like