Transporting from GitHub:
It would be nice if the admin web interface could be reachable over HTTPS with a (self-signed) certificate out of the box.
HTTPS makes it a lot harder to tamper with data and given the movement to HTTPS would make it a logical step for the future.
Would there be interest in changing the webserver for another package that could handle auto-HTTPS? Have to check the rest of the package to see if it's capable to handling the other functions, (PHP) but it would help with the self-signed issues.
Option to use Let's Encrypt for public facing servers would be nice. Used this on Mail-In-a-Box with zero hassle.
No benefit for home users without a domain as you'd need domain name and port 80/443 exposed.
It is irresponsible to develop scripts and have logins with http. I suggest that you developers deactivate it by default completely. It is not a big deal to have the installer generate a self signed certificate locally, when openSSL is available on the server.
When this facility is made available, to have any further enhancement - like Let's Encrypt one - is only going to be better. However, the basic installation of SSL ONLY is a must.
Thus, I suggest to have the following:
DEACTIVATE HTTP PORT 80 AND THE PATH /var/www/html BY DEFAULT!!!. It should only be installed, "if and only if" an user does not provide any other information.
Ask the user path of the admin scripts he may want to install in the directory. If none is given, install default. If none is given, install default path /var/www/html. For e.g. he gives path as /home/admin/public_html/pihole/admin, it should be fed into the /etc/lighttpd/external.conf.
Generate with openssl a pem and put it in the lighttpd dir.
Thus, /etc/lighttpd/external.conf will be as follows:
$SERVER["socket"] == ":8081" {
server.document-root = "/home/admin/public_html/pihole/admin"
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/ssl.domain.com.pem"
}
With this system, one could use any other webserver or proxy in parallel.
While the development has grown from a home device, one cannot AND MUST not neglect the possibility to install it on a vServer / Dedicated Server in a data center with several other services functioning in place. Here, such an install method will provide an excellent alternative.
Lastly, I refuse to believe that these scripts of pi-Hole is ever going to remain in homes of private people. The reason why such an awareness amongst developers is not in there in the making is simply because the main goal was as such home computers. Having said that, I fail to believe that it could be of less use on servers in datacenters around the world.
But from now on, if the developers could more shifting their eyes and look outside of their home windows, they would realize that there are millions waiting in the datacenters, who may want to use these extra-ordinary scripts of pi-Hole. Of course, many modifications may be required.
Let's Encrypt doesn't work when you have no publicly facing webserver or domain to host with.
Hello Mr. Schaper,
Exactly thats the reason why I mentioned in my suggestion above to have a fundamental possibility in the installer to generate one ssl certificate during the installation procedure.
THIS IS A MUST!
So if one wants to install the scripts on a Server in a datacenter with a public address, then one could still generate one ssl certificate during the installation and later change it.
But to have no possibility and have a mind blowing activity by novices, and I do not belong to that category, is not the very best option.
I suggest to have the installer change its behavior during the installation as follows:
A. Ask for a fundamental option: Install with a private or public IP i.e. at home of in a data center.
B. Based on the answer, if the install is mapped to a public DNS resolver or in a private network, it will make a lot of different install entries. The public IP install may check and help install services in parallel, which may not be necessary in a private environment.
Then, Lets Encrypt option may not be available in a private IP installation at all.
Many such things can begin to differ...
Pull requests are always welcome and are how Open Source projects grow.
And if you are going to have a public facing webserver, you aren't going to waste your port-forward on Pi-Hole alone.
Personally I use Let's Encrypt with Nginx as a reverse proxy for my home network.
The other problem is if a user is already using Let's Encrypt on a raspberry pi,,, having it as part of the Pi-Hole setup process might destroy a previous configuration. Pi-Hole isn't necessarily the first/only thing being installed on a single device. (even though i wish I had a dedicated pi just for it.)
Perfectly safe if there is no external access to the webui. If you need access to the webui remotely, install openvpn, and then connect to it. I don't allow direct access to my Pi-Hole, nor do I think that's a good idea.
As @deathbybandaid said, if you don't have external access web interface, there is no need to use https unless you're MITMed in your own home network
Dear Superusers Mr. Anudeep and deathbybandaid,
While the development has grown from a home device, one cannot AND MUST not neglect the possibility to install it on a vServer / Dedicated Server in a data center with several other services functioning in place. Here, such an install method will provide an excellent alternative.
What did my above text communicate to you both? I supported the idea of having https because the possibility to install outside of the home network is there. If both of you want to restrict discussion, that pihole should never ever be used with a public IP, then it is fine. But here, I am not interested to discuss further on such a restrictive and conservative discussions.
Thank you for your comments. As you have already posted code that solves the issue, I would suggest a Pull Request as the best choice for getting that into the mainline code.
We are volunteers doing this in our spare time, each developer with their own areas of specialty. We do not support commercial endeavors, nor running open resolvers with public facing control panels. We just can't. We don't have the time nor the man power to support that, we each have our own outside jobs that take precedence as they actually pay the bills. This support here is when we can, and we do our best to support the user base that is using our software as intended. Other users and Superusers may be able to assist you where we can't.
There may be something that is lost in translation, but hopefully this clears up this situation for you.
Hello Mr. Schaper,
As you have already posted code that solves the issue, I would suggest a Pull Request as the best choice for getting that into the mainline code.
Did you mean to tell me to make a pull request?
Well, I do not have pi-Hole installation anymore on my server because it did not work. I came here to see if others have similar problems and a solution was found on it. As I could not come forward after 21 messages under the title "Cannot update config from web interface | FTL received SIGTERM", I gave up and plan to continue - if and only if - I can save settings from the web interface. Currently, how pi-Hole functioned is not usable to me. Thus, I removed it completely.
Therefore, instead of me making a pull request, I suggest to add the above simple code in an extra file external.conf. This will need two minutes to add it in the default installation and mention a default SSL port in the help files.
If generation of a domain certificate is too much complicated, which obviously require some more coding, then I can understand. But that also should not refrain developers to achieve an encrypted transaction on users side.
For this, I suggest to add one default pem in the default installation signed with any such domain discourse.pi-hole.net.pem and add it in the default installation.
Consequently, if the discourse.pi-hole.net.pem and external.conf is present in the respective directory, then SSL will work out of the box and all browser calls will be encrypted.
The only problem here would be, that a browser will declare that the certificate does not match with the domain / subdomain name it is installed. Thats noo problem because the connection will still remain encrypted.
The SSL - https architecture will further remain in place even after an update because the external.conf file is not supposed to be overwritten.
If a user wants to change and generate his own certificate for SSL on that domain in question, he could do so later.
Even in home network, people use wireless. Thats where such SSL connection becomes important too, although not so trival as in a public network.
Is this solution fine, or do you still want me to make a pull request?
I indeed meant to ask you to make a pull request.
Ok, I will take time to do it. But for that I will have to reinstall pi-Hole again on my server, which did not work on changing settings from the web interface. And there is no solution provided by anyone too.
Thank you, we do appreciate all submissions to improve the code.
While we won't be installing a certificate as part of our install process, we have put together a document on how to enable SSL for your Web interface.
Closing as no new reply in 2 1/2 years and an accepted solution.