-
-
Save davidbalbert/6815258 to your computer and use it in GitHub Desktop.
########################################### | |
# IMPORTANT NOTE: | |
# | |
# As of asuswrt-merlin 380.67 Beta, you | |
# can now configure SSL certificates from | |
# the Webui, making these instructions | |
# unnecessary. | |
########################################### | |
# First, enable SSH in the Administration->System tab. | |
# Then log in to the device. | |
# Verify that https_crt_save is off | |
admin@RT-N66U:/tmp/home/root# nvram get https_crt_save | |
0 | |
# Enable https_crt_save and verify that it was set correctly | |
admin@RT-N66U:/tmp/home/root# nvram set https_crt_save=1 | |
admin@RT-N66U:/tmp/home/root# nvram get https_crt_save | |
1 | |
# Write your custom key and certificate to the ephemeral file system. | |
# Note that these files will not be preserved on restart. | |
admin@RT-N66U:/tmp/home/root# cat >/etc/key.pem | |
# paste in key | |
admin@RT-N66U:/tmp/home/root# cat >/etc/cert.pem | |
# paste in cert | |
# Verify https_crt_file is empty | |
admin@RT-N66U:/tmp/home/root# nvram get https_crt_file | |
admin@RT-N66U:/tmp/home/root# | |
# Restart httpd. When httpd starts up with https_crt_save enabled, it does the | |
# following: If /etc/cert.pem and /etc/key.pem exist, it tars them together and | |
# saves them in https_crt_file. If they do not exist (this would be the case | |
# on reboot) and https_crt_file exists, httpd will extract the contents of | |
# https_crt_file. You can see how this works in the start_ssl function here: | |
# https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/httpd/httpd.c | |
admin@RT-N66U:/tmp/home/root# service restart_httpd | |
# Ensure https_crt_file is now full | |
admin@RT-N66U:/tmp/home/root# nvram get https_crt_file | |
# ...snip... | |
# Reboot AP to make sure cert is put back on boot | |
admin@RT-N66U:/tmp/home/root# reboot |
Yep, that was the missing piece of the puzzle.
Extracting the existing /jffs/cert.tgz into a temp subdir, overwriting etc/key.pem and etc/cert.pem and recreating /jffs/cert.tgz then running nvram set https_crt_save=1 and service restart_httpd seems to do the trick.
Finally !! Thanks for your help !
Yep, that was the missing piece of the puzzle.
Extracting the existing /jffs/cert.tgz into a temp subdir, overwriting etc/key.pem and etc/cert.pem and recreating /jffs/cert.tgz then running nvram set https_crt_save=1 and service restart_httpd seems to do the trick.
Finally !! Thanks for your help !
I tryed exactly this and checked the md5 sum:
Before copy cert.tgz to /jffs/cert.tgz md5 was: ef7ba5b1ec34074a56c1349653860d82
after copy: 899f0ec767378c8e5a84079d4e6315d3 /jffs/cert.tgz
then I ran following commands:
nvram set https_crt_save=1
service restart_httpd
after last command, the md5 was ef7ba5b1ec34074a56c1349653860d82 (as initial).
I'm using: 3.0.0.4.388_24328-g1e6e634
any idea?
after last command, the md5 was ef7ba5b1ec34074a56c1349653860d82 (as initial). I'm using: 3.0.0.4.388_24328-g1e6e634 any idea?
Same here. I am happy for everyone who managed to upload and activate their own certificate, but lost hope for myself.
Maybe extract and retain the other files. The archive looks like this for me, which suggests in december I replaced the key and crt, but kept the rest. Perhaps if other files are missing it regenerates / restores it. I should have kept better notes...