Hey, it would be great, if the ca certificate could be included as issuer in the self signed certificate that is created. Because right now apps like Homarr won't be able to fetch the ca certificate from the pi-hole instance, which leads to a lot of users having issues with adding Pi-hole to the trust store of Homarr. If the certificate would be included in the self signed one, we could fetch the certificate and add the trust of the ca directly, if the user wants so.
Maybe I do not understand what you are asking for here. When you look into /etc/pihole/tls.pem, you'll see it contains the certificate as well as the private key. What would be needed in addition? I have never heard about Homarr before and I hope you understand that I don't really have the time ti setup such an instance for myself for checking this.
That's why I'm asking what you'd expect to see in this file in addition to what is in there now.
It's a self-signed certificate, meaning there is no Certification Authority for it. The certificate is it's own authority.
If you need more flexibility with your certificates, I suggest creating your own certification authority.
Hey, thank you for your response.
Homarr is one of those dashboard apps people use to have a single place to go to all their self hosted software and has an integration for Pi-Hole. The "problem" is not, that I as a single user am unable to get my certificate and rather, that our users need to add the certificate to Homarr so the Pi-Hole instance is trusted by our app. But because their is a tls.crt and a tls_ca.crt, Homarr is unable to fetch the certificate through a simple request as it only returns the tls.crt. So there is no possibility to trust the tls_ca.crt without the user manually retrieving it from the file system. That said, I completely understand if this feature will not be worked on and it was just an idea to make it possible for apps that integrate Pi-Hole to simplify the process of trusting the ssl certificate.
Thank you for your work on this software, appreciate it
I see. My apologies, it does seem there are two certificates that pi-hole uses, which would indicate a Certification Authority.
root@****:/etc/pihole# openssl verify tls.crt
CN = pi.hole
error 20 at 0 depth lookup: unable to get local issuer certificate
error tls.crt: verification failed`
root@*****:/etc/pihole# openssl verify tls_ca.crt
CN = pi.hole, O = Pi-hole, C = DE
error 18 at 0 depth lookup: self-signed certificate
error tls_ca.crt: verification failed
Failing validation for the CA certificate is normal since it's self-signed. The problem I believe @Meierschlumpf is referring to is this: error 20 at 0 depth lookup: unable to get local issuer certificate when trying to validate the self-signed certificate. Essentially there is no way to obtain the Certification Authority's certificate to validate the chain.
There are realistically two options to take:
- Adjust the certificate generation to only generate the self-signed certificate; without the tls_ca.crt
- Add the Authority Information Access (AIA) extension to the self signed certificate, and publish the CA's public key to the pi-hole's web server. When clients connect to pi.hole, they will download the CA's certificate at the same time.
It looks like mbedtls supports extensions via this function.
Either option looks feasible, but for simplicity's sake I think the first option might be better here.
The tls_ca.crt is just an extra file. You can grab this file and add it as trusted to your browser directly so the browser can validate the certificate, cfm. TLS/SSL - Pi-hole documentation
Hence, removing this file seems wrong.
Even when we add this AIA extension and browsers manage to download the CA ... why should they trust it? Doing this by default seems wrong and a super easy attack vector for servers hosted by malicious parties. Note that the CA generated by Pi-hole for you locally on your machine is obviously not related to any other upstream CA and, hence, not automatically trustworthy.
Removing the file would definitely break some things for people, I was suggesting a rewrite of the mbed functions to only create the one certificate, without a CA. This is the most elegant solution to this self-signed problem, IMO.
If a malicious party were to host a pi-hole server, there's nothing to stop them from adding their own certificate with an AIA extension regardless. The only thing that AIA extensions provide is forwarding the full certificate chain to computers that connect to the pi-hole webUI; instead of the broken chain with only the self-signed certificate. If the user/computer connecting wants to write a program to automatically trust the CA from pi-hole, that's on them.
AIA extensions are ubiquitous, even the Let's Encrypt certificate for this discourse site has one; although I believe it's a bit too complex for something like pi-hole. There is another option that I did not mention, which would be to bundle the CA certificate in with the tls.crt. I am not sure how feasible this would be with mbedtls.
@DL6ER I've just tested, all you'd have to do is append the CA cert to the tls.pem file
root@****:/etc/pihole# cat tls_ca.crt >> tls.pem
That will take an enormous amount of convincing to get me to do that.
1 Like
What're your concerns? It's not the CA's private key that's being shown, merely the public key to prove the chain is valid.
As a side note - looking over the certificate generation code, the CA's private key is not saved anywhere - meaning you can't renew the webserver's certificate unless you regenerate the CA
I'm not going to tie running Pi-hole on a local network to anything external for general use. I'm not going to publicly avow that a CA should be trusted. I'm not going to require that Pi-hole contain any kind of call-home code to operate.
1 Like
Those are valid concerns. In hindsight, adding an AIA extension was a bad recommendation for a project like this.
I've offered two other recommendations to fix the certificate chain, however. There's no calling home or externally, all it does is complete the certificate chain, as it should.
Adding the CA's public key to pi-hole's webserver certificate does NOT create a security hole as it stands currently. As per the code above, you never save the CA's private key. Even if pi-hole's CA file were compromised, there's nothing that anyone can do with it, as there's no private key to issue any further certificates with.
Edit: I'll make a pull request for it when I get home.
Thank you. It was a clearly forgotten when designing the self-signed certificate generation code. Already merged into development and will be part of the next Pi-hole FTL release.