I have a private.key for SSL that is password protected. What is the option variable to set in /etc/config/uhttpd config file to allow UHTTPD server to use the certificate and key i supplied?
Hmmm. A couple things. The public/private certs used for a web sever are different than SSH keys. Also, "unprotected" certs are are typically used as having the password unencrypted on the box means it doesn't add any significant amount of security.
I was referring to SSL for HTTPs, not SSH for OpenSSH.
I have the cert/key for HTTPs, the key is password protected. Is there a way to encrypt the password for UHTTPD server to use with the key i provide? Nginx is capable of using a file containing the password, and to use protected keys, i thought uhttpd could do the same.
It is perhaps a good idea to add support for this type of situation in the future no? should be easy in my understanding, to implement the option to uhttpd server/config.
nginx is now supported for LuCI, at least on master ("snapshot" builds). I believe the luci-ssl-nginx collection will install everything needed. uhttpd isn't something I'd recommend except for the space-starved on 4 MB units.
uhttpd is fine for its primary purpose, providing a simple and small webserver for the administrative webinterface (luci) - obviously it isn't the best (or even a suitable-) choice for advanced requirements (additional hosting, vhosts, etc.) beyond that (or accessibility from the outside or other hostile environments).
Thank you both for your reply.
@jeff i can't wait for master branch to be released as stable, i am working on a personal project. LuCi on Nginx was possible before, I was able to run LuCi on Nginx some time ago. My understanding from this, to this date, is that uhttpd server is not capable to use password protected SSL keys.
@slh i understand uhttpd server is to make openwrt compatible with as much routers as possible. I wish there was a way to simple way to remove memory chips on old routers and to solder bigger memory chips haha.
For many of us, master is the production branch of choice. Other than for testing default behavior, I can't remember the last time I flashed a "release" image. You just have to test your image before committing it to critical use. These days, the breakage if any on master is minimal, and I can't remember a time that it was not bootable after a flash.
@jeff I tried to compile directly from master branch, but i am getting an error compiling "quilt". I do not have the exact error now because i deleted the folder and reorganized a few things locally. But, i couldn't compile master branch last week. I am using the default config.seed generated by openwrt.
Start from zero and add just what you need. Using the “build everything” seed is a world of pain. Just selecting your target and board are enough for a bootable, runnable system.
Take note if you get that error again.