The issue I am facing: Updates fail with 'Unable to update local repo', CRL file selfsigned/missing
Details about my system: Pi 4B
**What I have changed since installing Pi-hole: NA
**
I checked the system clock. I attempted to run update-ca-certificates.
Running sudo pihole -up yields:
$ sudo pihole -up
[✓] Building dependency package pihole-meta.deb
[✓] Installing Pi-hole dependency package
[i] Checking for updates...
fatal: unable to access 'https://github.com/pi-hole/pi-hole.git/': server verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
Error: Unable to update local repository. Contact Pi-hole Support.
Github problem or my local config? Thanks.
This was an opaque issue/resolution for me and maybe it could be made clearer in a subsequent release.
The answer appears to have been to bypass Pi-Hole's upstream DNS temporarily and point explicitly to an open public server in /etc/resolv.conf
Nope: sudo pihole -up still fails.
If I switch temporarily to any DNS other than PiHole then pihole -up works. Switch back to pi-hole, it does not.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
sudo pihole -d
Thanks, RD.
It's:
https://tricorder.pi-hole.net/HP5sVdC6/
Also:
$ unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf
What do below two output?
apt policy ca-certificates
openssl s_client -connect github.com:443 -servername github.com -CAfile /etc/ssl/certs/ca-certificates.crt </dev/null
Try reinstalling:
sudo apt install --reinstall ca-certificates
And/or:
sudo update-ca-certificates
FYI:
$ man update-ca-certificates
[..]
DESCRIPTION
This manual page documents briefly the update-ca-certificates com‐
mand.
update-ca-certificates is a program that updates the directory
/etc/ssl/certs to hold SSL certificates and generates ca-certifi‐
cates.crt, a concatenated single-file list of certificates.
Hi,
I did already reinstall the CA certificate once I realized that I could do so with an alternative DNS, by both methods. There does in fact appear to be a self-signed cert.
ca-certificates:
Installed: 20250419
Candidate: 20250419
Version table:
\*\*\* 20250419 500
500 http://deb.debian.org/debian trixie/main arm64 Packages
500 http://deb.debian.org/debian trixie/main armhf Packages
100 /var/lib/dpkg/status
Connecting to 0.0.0.0
CONNECTED(00000003)
depth=1 CN=pi.hole, O=Pi-hole, C=DE
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=1 CN=pi.hole, O=Pi-hole, C=DE
verify return:1
depth=0 CN=pi.hole
verify return:1
---
## Certificate chain
0 s:CN=pi.hole
i:CN=pi.hole, O=Pi-hole, C=DE
a:PKEY: EC, (secp384r1); sigalg: ecdsa-with-SHA256
v:NotBefore: Jul 2 14:46:32 2026 GMT; NotAfter: Aug 18 14:46:32 2026 GMT
1 s:CN=pi.hole, O=Pi-hole, C=DE
i:CN=pi.hole, O=Pi-hole, C=DE
a:PKEY: EC, (secp384r1); sigalg: ecdsa-with-SHA256
v:NotBefore: Jul 2 14:46:32 2026 GMT; NotAfter: Aug 18 14:46:32 2026 GMT
---
## Server certificate
-----BEGIN CERTIFICATE-----
MIIB3jCCAWSgAwIBAgIPMzkzNDY0NzQwOTkzODExMAoGCCqGSM49BAMCMDExEDAO
BgNVBAMMB3BpLmhvbGUxEDAOBgNVBAoMB1BpLWhvbGUxCzAJBgNVBAYTAkRFMB4X
DTI2MDcwMjE0NDYzMloXDTI2MDgxODE0NDYzMlowEjEQMA4GA1UEAwwHcGkuaG9s
ZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABIfclLJH5Y3zV0R+4RMy8N2YToaQMBnv
FEzfF1VkiSL1jXujsqlLTmObZoxzJa6Ke4QMQVAg1gPFfQfCJ+ordp0cD2wCSjQ/
p+uKQARXCEnE6YHxcvBq9YpcnUJyn7ByPaNhMF8wHQYDVR0OBBYEFMh5VnIoKuO2
lDdmQ5Ysh78yjayfMB8GA1UdIwQYMBaAFBJAPa4jwRvwqqI2zsEgtxb0DiuhMAkG
A1UdEwQCMAAwEgYDVR0RBAswCYIHcGkuaG9sZTAKBggqhkjOPQQDAgNoADBlAjAY
QALlxB4kLkfKM/iccgfKPEGSs+61Nj66viCah25NyVNIl+WfiRudH+eRIu0GOwsC
MQC9jCJoPXbEbbI8Czio7nTYcdihWZNALk8vvBslXtXoPpbsTbBaI/fx1eByBlcu
9zc=
-----END CERTIFICATE-----
subject=CN=pi.hole
issuer=CN=pi.hole, O=Pi-hole, C=DE
## No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ecdsa_secp384r1_sha384
Peer Temp Key: X25519, 253 bits
---
## SSL handshake has read 1433 bytes and written 1632 bytes
Verification error: self-signed certificate in certificate chain
---
## New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 384 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self-signed certificate in certificate chain)
---
DONE
You have somehow redirected the github.com domain to resolve to the 0.0.0.0 IP.
Which in some implementations results in addressing the loopback IP 127.0.0.1 where Pi-hole is listening.
And the Pi-hole web daemon is answering instead of the servers from Github.
$ ip -br link show lo
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
$ ip -br address show lo
lo UNKNOWN 127.0.0.1/8 ::1/128
$ dig +short version.bind chaos txt @0.0.0.0
"dnsmasq-pi-hole-v2.92.2"
$ sudo pihole tail
[..]
Jul 8 00:34:50: query[TXT] version.bind from 127.0.0.1
Jul 8 00:34:50: config version.bind is <TXT>
EDIT: Oh below how looks like on mine:
$ openssl s_client -connect github.com:443 -servername github.com -CAfile /etc/ssl/certs/ca-certificates.crt </dev/null
CONNECTED(00000003)
depth=2 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root E46
verify return:1
depth=1 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV E36
verify return:1
depth=0 CN = github.com
verify return:1
---
Certificate chain
0 s:CN = github.com
i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV E36
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
v:NotBefore: Jul 3 00:00:00 2026 GMT; NotAfter: Sep 30 23:59:59 2026 GMT
1 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV E36
i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root E46
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Mar 21 23:59:59 2036 GMT
2 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root E46
i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Jan 18 23:59:59 2038 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID7jCCA5SgAwIBAgIQcgEOA/SgZ/5OeWJmQwcY9jAKBggqhkjOPQQDAjBgMQsw
CQYDVQQGEwJHQjEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQDEy5T
ZWN0aWdvIFB1YmxpYyBTZXJ2ZXIgQXV0aGVudGljYXRpb24gQ0EgRFYgRTM2MB4X
DTI2MDcwMzAwMDAwMFoXDTI2MDkzMDIzNTk1OVowFTETMBEGA1UEAxMKZ2l0aHVi
LmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABIWWMDSOi/1sMgquP4I/obBM
735wpzcIZi4fLeiBsToXVVSwjj4OPH+W6azHzxETM0gUP7raehddpJ8uwjqYsTij
ggJ5MIICdTAfBgNVHSMEGDAWgBQXmagEwW/kLXCoChA9A9PpGrgmYzAdBgNVHQ4E
FgQUEKU6Ytbv1gZWnty4gvzCe2hdPWkwDgYDVR0PAQH/BAQDAgeAMAwGA1UdEwEB
/wQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwSQYDVR0gBEIwQDA0BgsrBgEEAbIx
AQICBzAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZn
gQwBAgEwgYQGCCsGAQUFBwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5z
ZWN0aWdvLmNvbS9TZWN0aWdvUHVibGljU2VydmVyQXV0aGVudGljYXRpb25DQURW
RTM2LmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wggEF
BgorBgEEAdZ5AgQCBIH2BIHzAPEAdgDXbX0Q0af1d8LH6V/XAL/5gskzWmXh0LMB
cxfAyMVpdwAAAZ8lTHVtAAAEAwBHMEUCIQCkpa0ZYNwsPiMRLHz+kk1QS/W9bg/8
4yNBVGkT289dNQIgMWLgxYp6vGJXJxyD3c1NI1aZsPA7GqyLSXaZLZHgKh0AdwDI
o8R/x7OtuTVrAT9qehJt4zpOQ6XGRvmXrTl1mR3PmgAAAZ8lTHVhAAAEAwBIMEYC
IQDsO+TR8EVfCiObBPoDLRKzKLQ/uorsebJ2aZDIejA9RgIhAJ6dp7FqCD93tQXX
AF24pDIms1fX4dZ+VPzXGuD8u8t1MCUGA1UdEQQeMByCCmdpdGh1Yi5jb22CDnd3
dy5naXRodWIuY29tMAoGCCqGSM49BAMCA0gAMEUCIB0PC2GRSurxu8gCkSNsYxmw
kAtCNfCvpXRiif8PhGkmAiEAzBH4AVYAtv1FsMrJabD9FYcAql0EteKafckH2exj
Uag=
-----END CERTIFICATE-----
subject=CN = github.com
issuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV E36
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3088 bytes and written 380 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
After looking at your debug log, I can say your issue is expected.
I didn't check the lists to make sure they are not blocking Github, but since this is very unusual, I will consider your lists are not blocking it.
I didn't check all of your regex rules and exact domain rules (block and allow), because you have literally thousands of rules, but I found at least one regex rule that blocks Github:
27159 regex-deny yes 0 github.com
This will effectively block the domain, returning the IP 0.0.0.0 and it will cause the issue already explained by deHakkelaar.
Solution:
Do not use Pi-hole as DNS for the Pi-hole machine. Use a public DNS server instead.
We usually recommend that to avoid issues with pihole -up and pihole -r commands.
Alternatively, you can allow Github domains, at least for the Pi-hole machine.
I discovered the block at the same moment your response came in, and oh crap I just lost everything I'd been typing -- again.
Did not realize I had suddenly begun denying github. Solved my issue it seems by sudo pihole deny -d github.com (it was exact not regex).
Thank you very much.
Maybe you had another entry or it was edited after you generated your log, but the log shows regex-deny on the Group with ID=0 (Default group):
Please make sure the regex was removed too, just in case.
I did find that, as well. Thanks again very much.
Related, if anyone's written a script to list or optionally remove regexes which effectively duplicate, or could be superseded by, a subscribed list, a pointer to that would be helpful. I have been trying to find and catch those on the fly.
Not a script but a way to check duplicates.
Below domain is on the default OOTB block list:
$ pihole query flurry.com
Found 0 domains exactly matching 'flurry.com'.
Found 1 lists exactly matching 'flurry.com'.
- https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts (block)
- flurry.com
If I add a block regex:
$ sudo pihole regex '^.*flurry\.com$'
[✓] Added 1 domain(s):
- ^.*flurry\.com$
$ pihole query flurry.com
Found 1 domains exactly matching 'flurry.com'.
- ^.*flurry\.com$ (type: exact deny domain)
Found 1 lists exactly matching 'flurry.com'.
- https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts (block)
- flurry.com
All above can also be done via the webGUI.
I do that as well, commonly. To be clear I'd like to be able to perform a bulk operation. Can likely be done with a single SQLite command but I'm lazy to write one.
Am not sure if thats possible as some regex'es could have thousands and maybe millions of solutions/matches.
I guess you'd have to iterate into every one of them.
I don't think there is a simple way to do what you want.
If you have too many exact domains and regex rules, it is very hard to find "duplicates".
I was able to find some strange things, like this case:
As you can see, the Exact Deny rule and the Regex Deny rule are assigned to the Default group (ID=0), but the Allow rule is also assigned to the same group.
This combination will effectively block the youtube.com domain for everyone and all subdomains (except www.youtube.com, which is allowed). Is this what you want?
In any case, the exact-deny is completely unnecessary because the exact-allow will win (Allow rules always take precedence over block rules).
My suggestion is to check all entries or maybe even remove all of them and start adding only the rules you actually need.