-
-
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 |
According to the code as long as https_crt_save is set to 1 and https_crt_file is unset it should save, but for some reason It was refusing to save the certs to the nvram, I was able to manually save the file by:
tar -czf cert.tgz --transform 's,^,etc/,' cert.pem key.pem echo $(cat cert.tgz | base64 | tr -d '\n')And then copying this and pasting it into the router without newlines or spaces at the end (I couldnt paste into the command prompt as it would truncate)
vi /tmp/https_crt_file nvram set https_crt_file=$(cat /tmp/https_crt_file) nvram commit(Updated to add the commit, I also had to unplug power to stop it saving and overwriting the work I had done to create the correct nvram) Also there is no need to save https certificates nvram set https_crt_save=0
I tried this method, but following error occurred:
nvramhttps_crt_file value length is bigger than allowed max length:1024
I'm using the last firmware version, but on ASUS GT-AX11000.
When I try to load the https page, the browser says the certificate is empty. Running command:
nvram get https_crt_file
The output is empty.
Is anybody still able to use his own certificate?
@cristit try with the Web ui first to confirm your key+cert is working., ref https://gist.github.com/davidbalbert/6815258?permalink_comment_id=4047785#gistcomment-4047785
I'm guessing you're hitting a length limit, were you trying to concatenate intermediate certificates into your leaf maybe?
thanks @jebeaudet!
https://router.mydomain.abc says the certificate is empty.
what is the size of the file, when you try to read it the https_crt_file using:
nvram get https_crt_file
From this thread it seems EC certificates are not accepted so only RSA. I've used RSA2048. Also, make sure you don't concatene intermediate certificate, the certificate uploaded should be the one given by acme, nothing more nothing less.
This! This turned out to be the problem for me, on stock firmware at least. When I generated my certificates with "--key-type rsa" with certbot, the below commands worked without any problems. I used the exact same commands before on Asusmerlin, and that worked with EC certificates. But I had to revert back to stock firmware, and tried to import my own certificates again, but it did not work. So I think that Merlin has implemented them, but Asus hasn't (yet). Could that be the case?
I am on the ZenWifi XT-8, but I imagine this also goes for the RT-N66U.
So in short:
Copy cert files to:
/jffs/.cert/cert.pem
/jffs/.cert/key.pem
Restart the service
service restart_httpd
Its been a while since I have been in the gist, but for anyone using a Lets Encrypt certificate this script below combined with the following acme.sh command gets a working internal certificate
acme.sh --home /jffs/acme.sh --issue -d example.com --dns dns_cf --debug --fullchain-file /etc/cert.pem --key-file /etc/key.pem --reloadcmd "/jffs/acme.sh/installcertificate.sh"
/jffs/acme.sh/installcertificate.sh
#!/bin/sh
tar -C / -czf /jffs/cert.tgz etc/cert.pem etc/key.pem
nvram set https_crt_save=1
service restart_httpd
I followed every variant posted here with the default firmware 3.0.0.4.388_24621 (deleting all .pem files, copying the custom .pem files, creating the cert.tgz manually in /jffs/, nvram commands in every order ...) – every time I restart the httpd service, the default Asus cert gets (re-)created automatically and overwrite my certs. nvram get https_crt_file never returns anything. :(
Maybe try updating your firmware? I have RT-AC58U with 3.0.0.4.382_52504 firmware and here is the full script that works for me:
#!/bin/sh
rm ~/router.sh
cat <<EOT >> router.sh
#!/bin/sh
cd /etc
ls *.pem
rm *.pem
nvram set https_crt_save=0
nvram unset https_crt_file
service restart_httpd
echo "httpd restarted"
nvram unset https_crt_file
service restart_httpd
echo "httpd restarted"
nvram get https_crt_file
sleep 20
ls *.pem
rm *.pem
nvram set https_crt_save=1
cat <<EOT >> cert.pem
EOT
cat /etc/certificates/new/letsencrypt.crt >> router.sh
echo "" >> router.sh
echo "EOT" >> router.sh
cat <<EOT >> router.sh
cat <<EOT >> key.pem
EOT
cat /etc/certificates/new/letsencrypt.key >> router.sh
echo "EOT" >> router.sh
cat <<EOT >> router.sh
rm server.pem
cat key.pem > server.pem
cat cert.pem >> server.pem
service restart_httpd
nvram get https_crt_file
EOT
cat router.sh | ssh -o StrictHostKeyChecking=no \
-p 4092 -i privatekey.pem [email protected]
Unfortunately, 3.0.0.4.388_24621 is the latest firmware for my ZenWiFi AX (XT8) device, according to Asus' servers.
Something changed from some point after I wrote my comment above. But with what is current for my router (3.0.0.4.388_24329-g5906523) I was able to replace the certs.
I have this written down now.
mkdir tmp/etc
cd tmp
cat << EOF > etc/cert.pem
...
EOF
cat << EOF > etc/key.pem
...
EOF
tar -C / -czf /jffs/cert.tgz etc/cert.pem etc/key.pem
nvram set https_crt_save=1
service restart_httpd
Mostly, it looks like the difference is nvram set https_crt_save=1.
This is what I do (after creating cert.pem and key.pem in /jffs/):
cd /jffs/
rm cert.tgz
tar -czf cert.tgz cert.pem key.pem
nvram set https_crt_save=1
At this point nvram get https_crt_file returns nothing, and as soon as I execute service restart_httpd, the file cert.tgz gets overwritten by the system.
Maybe try updating your firmware? I have RT-AC58U with 3.0.0.4.382_52504 firmware and here is the full script that works for me:
...
If I execute the steps manually, this happens:
admin@ZenWiFi_XT8-A5C0:/tmp/etc# ls *.pem
cacert.pem cacert_gen.pem cakey.pem cakey_gen.pem cert.pem cert_gen.pem key.pem key_gen.pem server.pem
admin@ZenWiFi_XT8-A5C0:/tmp/etc# rm *.pem
admin@ZenWiFi_XT8-A5C0:/tmp/etc# nvram set https_crt_save=0
admin@ZenWiFi_XT8-A5C0:/tmp/etc# nvram unset https_crt_file
admin@ZenWiFi_XT8-A5C0:/tmp/etc# service restart_httpd
Done.
admin@ZenWiFi_XT8-A5C0:/tmp/etc# nvram unset https_crt_file
admin@ZenWiFi_XT8-A5C0:/tmp/etc# service restart_httpd
Done.
admin@ZenWiFi_XT8-A5C0:/tmp/etc# nvram get https_crt_file
admin@ZenWiFi_XT8-A5C0:/tmp/etc# sleep 20
admin@ZenWiFi_XT8-A5C0:/tmp/etc# ls *.pem
cacert.pem cacert_gen.pem cakey.pem cakey_gen.pem cert.pem cert_gen.pem key.pem key_gen.pem server.pem
admin@ZenWiFi_XT8-A5C0:/tmp/etc# rm *.pem
admin@ZenWiFi_XT8-A5C0:/tmp/etc# nvram set https_crt_save=1
admin@ZenWiFi_XT8-A5C0:/tmp/etc# cp /jffs/cert.pem .
admin@ZenWiFi_XT8-A5C0:/tmp/etc# cp /jffs/key.pem .
admin@ZenWiFi_XT8-A5C0:/tmp/etc# ll *.pem
-rw-rw-rw- 1 admin root 1249 Sep 3 08:12 cert.pem
-rw-rw-rw- 1 admin root 1704 Sep 3 08:12 key.pem
admin@ZenWiFi_XT8-A5C0:/tmp/etc# cat key.pem > server.pem
admin@ZenWiFi_XT8-A5C0:/tmp/etc# cat cert.pem >> server.pem
admin@ZenWiFi_XT8-A5C0:/tmp/etc# ls *.pem
cert.pem key.pem server.pem
admin@ZenWiFi_XT8-A5C0:/tmp/etc# service restart_httpd
Done.
admin@ZenWiFi_XT8-A5C0:/tmp/etc# nvram get https_crt_file
admin@ZenWiFi_XT8-A5C0:/tmp/etc# ls *.pem
cacert.pem cacert_gen.pem cakey.pem cakey_gen.pem cert.pem cert_gen.pem key.pem key_gen.pem server.pem
/jffs/cert/tgz is recreated after all the steps above, but nvram get https_crt_file still returns nothing (and the router still presents the Asus certificate).
Yep, I've got an RT-AX88U Pro running Merlin 3004.388.8_2 and I can't replace the ss cert via the cli either.
I can manually update it via the web UI so I know my cert.pem and key.pem are good, but when I follow the steps suggested, i.e.
With etc/cert.pem etc/key.pem being my validated pem based cert and private key
steph@xxx:/tmp# tar -C / -czf /jffs/cert.tgz etc/cert.pem etc/key.pem
steph@xxx:/tmp# tar -tzf /jffs/cert.tgz
etc/cert.pem
etc/key.pem
steph@xxx:/tmp# nvram set https_crt_save=1
steph@xxx:/tmp# service restart_httpd
Done.
I see that /jffs/cert.tgz is overwritten with a server cert issued by a local CA on the router and the archive contents look like this:
steph@xxx:/tmp# tar -tzf /jffs/cert.tgz
etc/cacert.pem
etc/cakey.pem
etc/cert.pem
etc/key.pem
etc/cacert_gen.pem
etc/cakey_gen.pem
etc/cert_gen.pem
etc/key_gen.pem
steph@xxx:/tmp#
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...
tar tzvf cert.tgz
-rw-rw-rw- 0/0 1517 2018-05-05 01:05:31 etc/cacert.pem
-rw------- 0/0 1679 2018-05-05 01:05:31 etc/cakey.pem
-rw-rw-rw- 0/0 1838 2023-12-19 22:53:50 etc/cert.pem
-rw------- 0/0 1704 2023-12-19 22:53:51 etc/key.pem
-rw-rw-rw- 0/0 1517 2018-05-05 01:05:31 etc/cacert_gen.pem
-rw------- 0/0 1679 2018-05-05 01:05:31 etc/cakey_gen.pem
-rw-rw-rw- 0/0 1838 2018-05-05 01:05:25 etc/cert_gen.pem
-rw------- 0/0 1675 2018-05-05 01:05:25 etc/key_gen.pem
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.
Nope, i only activated the nvram once and for all, I don't deactivate it to clean it and activate it after. I'm on the latest Merlin firmware for the ax88u (388 is in beta, I'm on the one just before)