-
-
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 |
Ok. In my case they get copied from /jffs to /etc/tmp after the service restarts.
ah, that's interesting, I'll give it a try in a free moment...
Seems to get more complicated every year. This time the magical combination was:
nvram set https_crt_save=0
cd /tmp/etc
cat > key.pem [paste the key, Enter, Ctrl+C]
cat > cert.pem [paste the cert, Enter, Ctrl+C]
rm server.pem
cd /jffs
cp /tmp/etc/key.pem ./
cp /tmp/etc/crt.pem ./
service restart_httpd
nvram set https_crt_save=1
Tried many other combinations and this was the only thing that would survive the reboot.
I'm running latest asusmerlin on 87U and all I had to do is to copy key and cert to jffs partition and then restart the httpd service.
Here's an example (I'm running it from NAS):
scp -i ./sshPrivKeyToConnectToRouter.pem /localLocationOfCertificates/*.mydomain.com.cer [email protected]:/jffs/.cert/cert.pem
scp -i ./sshPrivKeyToConnectToRouter.pem /localLocationOfCertificates/*.mydomain.com.key [email protected]:/jffs/.cert/key.pem
ssh -i ./sshPrivKeyToConnectToRouter.pem [email protected] service restart_httpdSo in short:
- Copy cert files to:
/jffs/.cert/cert.pem
/jffs/.cert/key.pem- Restart the service
service restart_httpd
Hey thanks man, I was having trouble finding the location of the certificates that persists 👍
Here's the Ansible version: https://github.com/tomdaley92/rt-ax88u
After fooling around with all the responses here. I stumbled upon the simple fact, when using the UI on
WAN >> DDNS >> Import Your Own Certificate >> Upload
For the key file and certificate file, you MUST supply files named key.pem and cert.pem
This ensures that the files are accepted and persisted to your configuration. My files were initially named differently.
[RFE] - Please include a statement as to the proper naming of the files, OR simply rename the files when they are saved to the router. I would consider this a bug. A user should not have to name the files specifically unless they are provided with a prompt to do so or warning/error when the provided files are not named appropriately.
Just struggled too long on this. Make sure you can first upload the key/cert through the UI and that's it's accepted. If it keeps going back to the auto generated asus one, it means that the firmware did not accept your certificate. The "Server Certificate" section needs to show your own certificate info!
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.
Once that done and clear, you can copy your cert/key to /jffs/.cert and you should be good to go.
Yeah, the DDNS page hack by @parmstro worked for me as well with the current official Asus firmware (3.0.0.4.386_46065). The only thing is that in AP mode, which I am using, this page is not linked in menus, so one has to hit it directly, For example:
https://:8443/Advanced_ASUSDDNS_Content.asp
I then pretended to enable the DDNS client (will not work, but that's not relevant) and uploaded key/cert in PEM format and hit Apply.
PS. I later disabled the non-working DDNS setup and the uploaded key/cert were left alone (i.e. still survived a reboot).
On the latest stock firmware (3.0.0.4.386_49703):
mkdir -p tmp/etc
cd tmp
cat << EOF > etc/cert.pem
...
EOF
cat << EOF > etc/key.pem
...
EOF
tar zcvf cert.tgz etc/cert.pem etc/key.pem
mv /jffs/cert.tgz /jffs/cert.tgz.bak
mv cert.tgz /jffs/
service restart_httpd
Test, if satisfied, reboot and it should persist.
On the latest stock firmware (3.0.0.4.386_49703):
mkdir -p tmp/etc cd tmp cat << EOF > etc/cert.pem ... EOF cat << EOF > etc/key.pem ... EOF tar zcvf cert.tgz etc/cert.pem etc/key.pem mv /jffs/cert.tgz /jffs/cert.tgz.bak mv cert.tgz /jffs/ service restart_httpdTest, if satisfied,
rebootand it should persist.
Hey thanks for the script, I tried using it and apparently my ax88 doesn't use the new updated certs, still using the old ones. Is there a file that I need to remove or something? I didn't do the nvram stuff though, not sure if it will help.
Thanks 🙏
I didn't do the nvram stuff though, not sure if it will help.
Yes, the "nvram stuff" is required. It clears the old cert before saving the new one.
Just checked and the nvram was already at 1.
I managed to make it work, apparently I didn't put the certs in the good area : I was putting them in /etc instead of /jffs/.cert
So my script is :
- copy from my NAS the cert.pem and key.pem to /jffs/.cert/
- tar the two
- remove old tar backup and create new one under /jffs/
- move tar
- reboot httpd
Since my certfs expire in 80 days, we'll see if my script works or not :)
Thanks!
And have you kept the nvram commands?
And have you kept the nvram commands?
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)
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.
OK, thanks, just checked and certificates are not in the jffs directory. The are in /etc directory. Anyway so far it work