OK so SOMETHING version 6 is doing to validate certs does not like certs generated by a PaloAlto Networks Firewall CA. I created a new CA in TrueNAS, then had it generate a cert... popped it into Pi-Hole and pointed to it and it pops right up no issues.... all certs generated from my PAN device are working on all other servers and applications but something in Pi-Hole does not like those x.509 certs 
1 Like
I was afraid so. Those appliances tend to introduce something into those certs that linux systems don't like. But it is good that it works now.
yeah i was fighting it and fighting it so this was a last ditch effort and it worked.... not sure why i dont have any issues with anything else but i can relax now 
I just hope this helps others having similar or same issue
v6 introduced some breaking changes since it no longer uses lighttpd.
I created guides get get TLS certs working on v6:
1 Like
I like the guide Pi-hole v6: Creating Your Own Self-Signed SSL Certificates. Also quite nice that you immediately explained the EC generation and not RSA.
What you could add:
- listing some other curves to be used - not everyone likes the NIST recommended ones. This link here provides a good overview I believe: https://thalesdocs.com/gphsm/luna/7/docs/network/Content/sdk/using/ecc_curve_cross-reference.htm
- how to check the output of openssl via -text to see what really went into the certificate or the CSR.
These are good suggestions. I'm curious what makes other curves more desirable than other (besides low strength ones like 64 bits, etc.). What would make someone not use a NIST-recommended one?
I tried to use it with my own certificate, regarding to the logfile the certificate was loaded correctly
2025-02-22 16:04:22.268 CET [320946M] INFO: Reading certificate from /etc/pihole/pi-hole_key-cert.pem ...
2025-02-22 16:04:22.268 CET [320946M] INFO: Using SSL/TLS certificate file /etc/pihole/pi-hole_key-cert.pem
2025-02-22 16:04:22.269 CET [320946M] INFO: Web server ports:
2025-02-22 16:04:22.269 CET [320946M] INFO: - 80 (HTTP, IPv4, optional)
2025-02-22 16:04:22.269 CET [320946M] INFO: - 443 (HTTPS, IPv4, optional)
2025-02-22 16:04:22.269 CET [320946M] INFO: - 80 (HTTP, IPv6, optional)
2025-02-22 16:04:22.269 CET [320946M] INFO: - 443 (HTTPS, IPv6, optional)
But with my certficate https isn't working anymore
Ever since NIST accepted that random number generator that is supposed to have an NSA backdoor (or weak spot), people tend to tread carefully with NIST. Therefore the brainpool curves seem to come from academia and more scrutinized. Even your BSI recommends a brainpool curve in one of their tech advisories.
Did you check the certificate entries?
Try openssl x509 -in </path/tp/certfile> -text. Check if there is something off with the algorithms, dates etc. New browser versions tend to be picky there.
But given the error message it looks like there is no valid reply from port 443 via TLS. Although the log file states otherwise. Strange.
Did you accept the CA certificate in your Windows cert store as trused?
I guess that post was for me?
Yes i have, i use several certificates that are signed by my CA
For mee it looks correct
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15 (0xf)
Signature Algorithm: ecdsa-with-SHA256
Issuer: O=xx, OU=CA/emailAddress=x@gmail.com, L=xx, ST=xx, C=DE, CN=root CA
Validity
Not Before: Feb 23 12:39:48 2025 GMT
Not After : Feb 21 12:39:48 2035 GMT
Subject: C=DE, ST=xx, O=xx, OU=CA, CN=pi-hole
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:33:2b:49:94:fd:af:96:ba:ea:6d:2c:ec:b6:73:
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
4D:99:F7:B2:1A:DE:0A:81:97:C7:09:53:E8:CA:60:B5:A0:22:88:37
X509v3 Authority Key Identifier:
0B:C7:4A:8F:D5:F7:11:FA:5C:DF:D5:34:B4:EE:18:48:91:04:3E:CF
X509v3 Key Usage: critical
Certificate Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, ipsec Internet Key Exchange
X509v3 Subject Alternative Name:
IP Address:192.1.1.1, IP Address:FDCA:, IP Address:FE80:, DNS:pi-hole
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:65:02:30:68:4e:13:a3:25:79:80:7d:69:5f:0d:34:4e:83:
I guees that it is an problem of the webserver that is not supporting the needed chiphers
# Fehler: Gesicherte Verbindung fehlgeschlagen
Beim Verbinden mit pi-hole trat ein Fehler auf. Die SSL-Gegenstelle konnte keinen akzeptablen Satz an Sicherheitsparametern aushandeln.
I have my own Let's Encrypt running fine in pi-hole v6 using docker compose on my Synology NAS. Docker or no docker, this info might help you.
My Synology has the Let's Encrypt files stored here (random 6 characters after _archive):
/usr/syno/etc/certificate/_archive/jIfyWk/privkey.pem/usr/syno/etc/certificate/_archive/jIfyWk/fullchain.pem
I store my pi-hole docker persistant data here: /volume1/docker/pi-hole/
My docker compose.yaml file:
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
ports:
- "53:53/tcp"
- "53:53/udp"
- "5380:80/tcp"
- "53443:443/tcp"
environment:
TZ: 'Europe/Oslo'
FTLCONF_webserver_api_password: 'not my secret password'
FTLCONF_dns_listeningMode: 'all'
volumes:
- /volume1/docker/pi-hole/etc-pihole:/etc/pihole
- /volume1/docker/pi-hole/entrypoint.sh:/entrypoint.sh
cap_add:
- SYS_TIME
- SYS_NICE
- CHOWN
- NET_BIND_SERVICE
restart: unless-stopped
secrets:
- privkey.pem
- fullchain.pem
entrypoint: ["/bin/sh", "/entrypoint.sh"]
command: ["/usr/bin/start.sh"]
labels:
com.centurylinklabs.watchtower.monitor-only: "true"
secrets:
privkey.pem:
file: /usr/syno/etc/certificate/_archive/jIfyWk/privkey.pem
fullchain.pem:
file: /usr/syno/etc/certificate/_archive/jIfyWk/fullchain.pem
The "secret source" here is to get the two cert files, key and chain, concatenated into /etc/pihole/tls.pem before pi-hole starts.
This is done with an entrypoint.sh script I call first, before starting pi-hole, and it concatinates the /run/secrets/{privkey.pem,fullchain.pem} files:
#!/bin/sh
# Combine private key and fullchain into a single file at /etc/pihole/tls.pem
cat /run/secrets/privkey.pem /run/secrets/fullchain.pem > /etc/pihole/tls.pem
chmod 660 /etc/pihole/tls.pem
echo "Installed Let's Encrypt certificate created from key and chain file in /run/secrets/" > /etc/pihole/tls.readme
# Execute the original container entrypoint
exec "$@"
So it's "just" the key, and then the cert chain, concatenated into /etc/pihole/tls.pem.
Only annoyance so far is Pi-hole diagnostics warning:
SSL/TLS certificate /etc/pihole/tls.pem does not match domain pi.hole !
I think I can get that gone by manipulating the pihole.toml file, just haven't gotten around to it.
1 Like
I'm using a Comodo Wildcard SSL cert. It works great on all of my other systems, and this exact cert worked perfectly fine with lighttpd in PiHole 5. But, same as you, I've tried all of the solutions listed here and in other threads and I simply cannot get it to work.
My first guess would be that it has issues with wildcards. Can you check what happens with a cert without?
I've never had any issues with wildcard certs before. Just for the hell of it, I created my own self-signed cert using OpenSSL and that didn't work either. Something is broken. Like I said, I'm not having any issues doing this on any of my other servers. This exact same cert worked fine using lighttpd. I'll probably just reinstall PiHole from scratch and see if that fixes it.
I'm struggling with certificates as well. I had an existing working installation of v6.0 and I reinstalled Pi-hole on it; I have an ansible playbook that does installs the certificate if needed (from my own CA), sets up the setupVars.conf, runs the install script and then tweaks the pihole.toml file. It worked before the reinstall and now it doesn't and I can't work out why, having tried all the suggestions above. This is on AlmaLinux 9.4 so "technically" unsupported (but that won't stop Pi-Hole working).
It would be good if there was a more verbose version of "Error initializing SSL context" so I could see what the error was. For the moment, I'm back to HTTP.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.