I do not see the files that are to be bound inside /jffs/etc:
my_certificate.pem for cert.pem
my_key.pem for key.pem
my_privkey.pem for privkey.pem
So check all file names that they match in /jffs/etc and in the script.
The easiest way to check if a config script is started is to write date and time into a text file, e.g.:
Code:
(place directly as the first commands after #!/bin/sh)
echo 'startup.config' >>/tmp/myconfig.log
date >>/tmp/myconfig.log
(and these after determination of MOUNT_PATH)
echo " SELF_PATH: ${SELF_PATH}" >>/tmp/myconfig.log
echo " MOUNT_PATH: ${MOUNT_PATH}" >>/tmp/myconfig.log
If it is not started, then check the owner, group and permission of the script plus all related DD-Wrt settings.
Additionally try to manually start the startup script and see if ${MOUNT_PATH} is correctly determined.
If it is started, then check out the log and it may have to be adapted to the new DD-Wrt release.
Many thanks for your guidance Maddes; great diagnostic approach, turns out the startup script is not running. I've triple checked perms and ownership, I don't see anything preventing it from running, do you?
Code:
root@r7000:/jffs/etc/config# ls -la
drwxr-xr-x 2 root root 0 Mar 3 18:49 .
drwxr-xr-x 4 root root 0 Mar 3 18:49 ..
-rwxr-xr-x 1 root root 1024 Mar 3 18:49 binds_on_mount.startup
As a test, I injected the output commands to echo myconfig.log into the 'startup command' in the GUI and it processed successfully; has something changed in the DD-WRT builds for startup configs (or am I missing something in the execute permissions)?
I've tried what feels like everything now. Have you had a chance to test on a newer WRT build? The only functional method I have at this time is with a startup script (thus unfortunately chewing up my NVRAM).
Got it working, sharing for anyone else with similar issue.
Turns out my problem was that the /jffs on my external USB was mounting *after* the /jffs automount from internal memory, therefore the .startup script I was modifying and testing was not actually running on startup but only when I manually tested it from the shell.
mount -o bind /tmp/ssl/cert.pem /etc/cert.pem
mount -o bind /tmp/ssl/key.pem /etc/key.pem
stopservice httpd
startservice httpd
I used the above on a Linksys E3000 SVN 24160 K3 (BrainSlayer) & it worked perfectly
This bricked my WNR3500L. Trashed stuff in board_data.
Had a WNDR3700v4 I'd been meaning to switch to lying around. Got jffs up and running on it, and just put this in startup:
Code:
mount -o bind /jffs/etc/ssl/cert-combined.pem /etc/cert.pem
mount -o bind /jffs/etc/ssl/key.pem /etc/key.pem
mount -o bind /jffs/etc/ssl/privkey.pem /etc/privkey.pem
stopservice httpd
startservice httpd
Works great! And not really too upset about losing the WNR3500L. May try to salvage it, but I like the new one better anyway.
@metsfan:
As stated in this post of this thread it is not a good idea to use NVRAM to store long keys.
Use JFFS on flash rom or a USB stick to keep the key as a file outside NVRAM (as you have done with your WNDR3700v4).
@metsfan:
As stated in this post of this thread it is not a good idea to use NVRAM to store long keys.
Use JFFS on flash rom or a USB stick to keep the key as a file outside NVRAM (as you have done with your WNDR3700v4).
I'm using a StartCom Class 2 certificate. It uses an intermediate certificate that is not in all browser certificate stores. On other sites, I just concatenate the certificates together into one file, and it works fine.
Code:
cat mycert.pem intermediatecert.pem > cert.pem
It seems the dd-wrt httpd is only serving up my certificate, not the intermediate one as well. Has anyone run into this?
I guess it's not really a big deal. Desktop browsers seem to work. Chrome for Android (and online SSL testers) seem to be the only place it causes a problem.
Edit: Strangely, my Chrome Android issue has gone away here, now gives me the green lock. Online checker still says it's an incomplete certificate chain, though.
I'm using a StartCom Class 2 certificate. It uses an intermediate certificate that is not in all browser certificate stores. On other sites, I just concatenate the certificates together into one file, and it works fine.
Code:
cat mycert.pem intermediatecert.pem > cert.pem
It seems the dd-wrt httpd is only serving up my certificate, not the intermediate one as well. Has anyone run into this?
I guess it's not really a big deal. Desktop browsers seem to work. Chrome for Android (and online SSL testers) seem to be the only place it causes a problem.
Edit: Strangely, my Chrome Android issue has gone away here, now gives me the green lock. Online checker still says it's an incomplete certificate chain, though.
Same issue here. I am using an older build though (kongac build 24345M works best on my router). So, maybe I should try a newer build and see if the problem has been fixed.
For the time being I'm just going to add the intermediate CA to my Android certificate store. It creates an annoying "your network may be monitored" warning at boot, but I'd rather have that notification once on boot than this SSL error every time I browse to my router URL. Especially since Chrome on Android doesn't really give you enough information to know if you're the victim of a man-in-the-middle attack (can't view cert details).
I'm using a StartCom Class 2 certificate. [...] Desktop browsers seem to work. [...]
StartCom Class 2: +1 here
I can't get it to work at all on 25408. I can confirm that the certificate content gets copied into the pem files which are mounted into /etc. Even when i restarted httpd service afterwards, every browser tells me the site is not reachable.
Would you write down a short tutorial on how you got at least this far? Thanks for your effort!
Now I have taken this spacing ad literam and actually used as many characters as shown in that post, then hitting new row, and continuing. Was that needed or was it just for readability's sake and the cert is supposed to have no returns/new rows in the key? When I generated the cert in OpenSSL, it didn't use that separation.
2. I generated an RSA-4096 key instead of 2048. Are those supported or not? This is the command line I used:
3. When I try to connect via HTTPS, both Firefox and Internet Explorer report a vague problem with the certificate just like before. But I would like to actually see the certificate. When you're connected to a website I know you can see its certificate, but when the connection is refused, is there any way to see it? I'd like to see if my cert is actually in there, and if it is readable at all.