Posted: Mon Aug 03, 2015 5:45 Post subject: Is this possible
I am trying to avoid the connection un-trusted error whenever I connect using https to my router. My thoughts are:
1. Create a CA that I add as a certificate to my browser using the instructions from http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/
2. Use this CA to sign a new certificate for my router
3. Replace the current certificates on my dd-wrt router with the new signed certificates.
I am not sure which files are needed. Do I need all three file (cert.pem, key.pem, privkey.pen)?
Fast forward to 2017. HTTPS has become the norm. Browsers are rejecting self-signed certificates and other certificates without an issuer chain. And there is now a free service (letsencrypt.org) that will issue trusted certificates for your domain. Finally, Kong builds, at least, now include lighttpd servers by default.
I created a wiki article linked below that describes how to set up DD-WRT to use such a trusted, free certificate for a domain you control, served by lighttpd.
Fast forward to 2017. HTTPS has become the norm. Browsers are rejecting self-signed certificates and other certificates without an issuer chain. And there is now a free service (letsencrypt.org) that will issue trusted certificates for your domain. Finally, Kong builds, at least, now include lighttpd servers by default.
I created a wiki article linked below that describes how to set up DD-WRT to use such a trusted, free certificate for a domain you control, served by lighttpd.
Fast forward to 2017. HTTPS has become the norm. Browsers are rejecting self-signed certificates and other certificates without an issuer chain. And there is now a free service (letsencrypt.org) that will issue trusted certificates for your domain. Finally, Kong builds, at least, now include lighttpd servers by default.
I created a wiki article linked below that describes how to set up DD-WRT to use such a trusted, free certificate for a domain you control, served by lighttpd.
Awesome, now all my internal x86 dd-wrt routers are using Let's Encrypt certificates via nsupdate dnsapi. Have to find a decent way to script the replacement of httpd GUI certificates but all in all very neat piece of code. Thanks!
Posted: Thu Mar 05, 2020 11:24 Post subject: Setup certs from letsencrypt
Thanks to the OP for this solution. As things changed a little bit since his solution, I give an up to date one here.
As last visitor asked what to set, I post my actions.
I use letsencrypt on a different computer (not on the router).
I did the following all the actions are done on the router shell (so you have to know how to ssh to your router first):
mkdir -p /jffs/etc/ssl
ssh xxx.xxx.xxx.xxx # (ssh to my letsencrypt server)
cd /etc/letsencrypt/archive/my.domain.com
# here, you will find your keys (maybe several sets of them)
# So, you have to replace the _x_ in the following command by the latest number you find in this directory...
# 192.168.1.1 is the router's IP
scp privkey_x_.pem cert_x_.pem fullchain_x_.pem 192.168.1.1:/jffs/etc/ssl
...
exit # to return to the router
To use immediately, do:
stopservice httpd
mount -o bind /jffs/etc/ssl/key.pem /etc/key.pem
mount -o bind /jffs/etc/ssl/host.pem /etc/host.pem
mount -o bind /jffs/etc/ssl/cert.pem /etc/cert.pem
startservice httpd
# (here, ls /etc/*.pem should show files with the size of your certificates, and the connection to the router with your my.domain.com:port website should work with the certificate)
Then, to get the change at each reboot, go in the router website, Administration/Commands (page is called Diagnostics.asp). Click the Edit button in the startup text field, then add:
stopservice httpd
mount -o bind /jffs/etc/ssl/key.pem /etc/key.pem
mount -o bind /jffs/etc/ssl/host.pem /etc/host.pem
mount -o bind /jffs/etc/ssl/cert.pem /etc/cert.pem
startservice httpd
Click the "Save Startup" button at the bottom.
Don't forget that the certificates changes every 3 months... You have to plan something to get them here again at the next renewal.
Posted: Thu Mar 03, 2022 9:29 Post subject: Certificate-Chain still not working
I configured via JFFS.
=> Browser works
=> Mobile not
It seems the intermediate certificate does not get served by httpd allthough I placed the correct chain in cert.pem
Does anybody know when this gets fixed?
For anybody wondering. HTTPD does not really serve a certificate chain. It just serves 1 certificate. Even though you write a chain in cert.pem only the first certificate gets served from the server.
Browser do cache certificates. So thats why it worked for me on Desktop but not on Mobile.
If somebody got a self-signed certificate-chain (with an own CA and an intermediate certificate), the only way to get DD-WRT so serve a correct "chain" is if you leave out the intermediate. The chain-structure just consists of: Root-Certificate --> Server-Certificate. This is considered a security-flaw but works for me as the router is only local.
Hope this helps someone.
Posted: Tue Mar 15, 2022 23:14 Post subject: Confirmed
DerHimmelUberBerlin wrote:
For anybody wondering. HTTPD does not really serve a certificate chain. It just serves 1 certificate. Even though you write a chain in cert.pem only the first certificate gets served from the server.
Browser do cache certificates. So thats why it worked for me on Desktop but not on Mobile.
If somebody got a self-signed certificate-chain (with an own CA and an intermediate certificate), the only way to get DD-WRT so serve a correct "chain" is if you leave out the intermediate. The chain-structure just consists of: Root-Certificate --> Server-Certificate. This is considered a security-flaw but works for me as the router is only local.
Hope this helps someone.
I'm a long time users and lurker. I registered a new account to contribute to the conversation about something that is just too annoying to not speak up about.
Could have used your comment over a week ago after years of getting around to installing a certificate with an intermediate certificate authority on the chain.
The key.pem, cert.pem, and host.pem was voodoo with barely any documentation about what they did until I went to look at the source code.
For milli_httpd:
cert.pem - Is supposed to contain the server's signed certificate plus intermediate certificate(s)
key.pem - Is the server's private key
For lighttpd (serves web pages from /jffs/www over https only, http remains serving the router's milli_httpd DD-WRT admin pages)
host.pem - Is supposed to contain the server's private key, server's signed certificate, plus intermediate certificate(s)
There are four types of users:
1. Some people directly used a root certificate to sign the server's certificate
2. Some people got the intermediate certificate(s) to work because of their browser caching the intermediate certificates
3. Some people installed the intermediate certificate(s) to make this work
4. Some people like ourselves think wtf. Something is broken.
We fall into the #4 class of people.
The reason why adding the intermediate certificates to the end of the cert.pem doesn't work is because httpd.c (milli_httpd) implementation calls SSL_CTX_use_certificate_file(). Right in the OpenSSL document says it only reads in the first certificate found from the target file. The implementation actually needs to call SSL_CTX_use_certificate_chain_file() instead to make the certificate chain work but for whatever legacy reason nobody ever fixed this. My guess is probably because most people like yourself were home users doing self-signed certificates using the root authority. As you said this doesn't work for enterprise environments nor for power users because using the root private key to sign server certificates is really a security risk unless the developers only ever intended for non-power users, and maybe reserved these features for their professional baseline. I did see registered users featurizations but I didn't see anything in particular that called the chain file API call. My bet is this problem still exists in the professional baseline.
https://svn.dd-wrt.com/browser/src/router/httpd/httpd.c#L1633
Maybe someone can get around fixing this. A mod? Thanks.
Note:
I tested on the March 1, 2022 release and checked the SVN codebase.
I've used the DCOverlords instructions to create a certificate authority - which I then import into Windows as per instructions - it can be imported into a dev machine and will survive sysprepping if that's your jam.
Then, from ChristianFr (with a USB drive mounted as /jffs and a bit of winscp'ing)
ChristianFr wrote:
To use immediately, do:
stopservice httpd
mount -o bind /jffs/etc/ssl/key.pem /etc/key.pem
mount -o bind /jffs/etc/ssl/host.pem /etc/host.pem
mount -o bind /jffs/etc/ssl/cert.pem /etc/cert.pem
startservice httpd
# (here, ls /etc/*.pem should show files with the size of your certificates, and the connection to the router with your my.domain.com:port website should work with the certificate)
Then, to get the change at each reboot, go in the router website, Administration/Commands (page is called Diagnostics.asp). Click the Edit button in the startup text field, then add:
stopservice httpd
mount -o bind /jffs/etc/ssl/key.pem /etc/key.pem
mount -o bind /jffs/etc/ssl/host.pem /etc/host.pem
mount -o bind /jffs/etc/ssl/cert.pem /etc/cert.pem
startservice httpd
Click the "Save Startup" button at the bottom.
This will deliver a seamless SSL experience, at least internally on your LAN. Firefox is additionally hardened to deny the system certificate store unless you change "security.enterprise_roots.enabled" in about:config. Chrome I think just works.
Posted: Sat Oct 28, 2023 5:33 Post subject: Re: Confirmed
superlazy wrote:
The key.pem, cert.pem, and host.pem was voodoo with barely any documentation about what they did until I went to look at the source code.
For milli_httpd:
cert.pem - Is supposed to contain the server's signed certificate plus intermediate certificate(s)
key.pem - Is the server's private key
For lighttpd (serves web pages from /jffs/www over https only, http remains serving the router's milli_httpd DD-WRT admin pages)
host.pem - Is supposed to contain the server's private key, server's signed certificate, plus intermediate certificate(s)
You have, in one stroke, cleared all my doubts, and I'm now able to make both httpd and lighttpd work.
Thanks for your valuable time and effort!
