How to use my own SSL certificates without having them reset?

Discussion in 'Tomato Firmware' started by Nazgulled, Nov 7, 2017.

  1. Nazgulled

    Nazgulled Serious Server Member

    I followed the instructions here to use my own SSL certificates for HTTPS to my router. As mentioned in the last line:

    I made sure the "Regenerate" box was UNCHECKED and that the "Save in NVRAM" was CHECKED.

    But a simple reboot of the router cleared my certificate and I had to do evrything all over again. Which feels pointless because I can't be bothered to these steps every time I decide or need to reboot my router for whatever reason.

    Am I doing something wrong or is there a better way to persist these changes after reboots?
  2. ruggerof

    ruggerof Network Guru Member

    What I do is to store them in my USB stick and copy them to /tmp/etc via a script when the USB stick is mounted, simple and efficient.
  3. Nazgulled

    Nazgulled Serious Server Member

    There's really no better way? :(
  4. jerrm

    jerrm Network Guru Member

    None of the nvram setfile functions exist in ARM, so that post just doesn't apply. Something different is being used to encode and store the cert info for ARM builds.

    The https_crt_file value looks base64-ish but a simple "nvram get https_crt_file | openssl enc -base64 -d" doesn't yield any output.

    Some source searching would probably show exactly how the cert info is being encoded before saving to nvram.

    Almost certainly it could be duplicated with command line tools.

    Otherwise use the USB method, or save the certs to nvram using your own variable and restore in the init script.
  5. Nazgulled

    Nazgulled Serious Server Member

    What do you mean? I followed that to the letter and it worked just fine. What am I not understanding here?

    Not exactly sure how would I achieve that. Any pointers or a guide to get this persisting reboots?
  6. Monk E. Boy

    Monk E. Boy Network Guru Member

    (scratches head) How can it be working just fine if it doesn't persist across reboots?
  7. Nazgulled

    Nazgulled Serious Server Member

    You said "None of the nvram setfile functions exist in ARM, so that post just doesn't apply." and what I take from this is that nothing in that link applies to my router, meaning that nothing should be working. Maybe I misunderstood something. English is not my first language. Sorry.

    But can you help me do it right?
  8. ruggerof

    ruggerof Network Guru Member

    This is exactly the point, the NVRAM command

    nvram setfb64 https_crt_file /tmp/cert.tgz
    is not available in ARM as already mentioned by @jerm
  9. Nazgulled

    Nazgulled Serious Server Member

    What does that mean exactly? I have an AC68U, isn't that command available? Because I've executed and it didn't fail or anything... :/ That's the source of my confusion.
  10. ruggerof

    ruggerof Network Guru Member

    Correct, it is not available and upon execution it will not provide you with any feedback.
  11. Nazgulled

    Nazgulled Serious Server Member

    So, in other words, replacing /etc/cert.pem and /etc/key.pem with my own files followed by service httpd restart, is enough to simply use (but not persist) my own self-signed certificate on the router?

    What would be my best course of action to persist this? Could I copy my own files to some location on the router and use some copy commands to replace the files on /etc/ with my own, followed by the restart of the httpd service and place all that in the init scripts section to execute during every reboot? Is that it?

    Follow up questions... Where can/should I store my own files on the router? What's the recommended location for this? Excluding installing new firmware versions, would my files persist forever or is there any other situation they would get deleted?
  12. jerrm

    jerrm Network Guru Member

    USB, jffs, or nvram (with a method that works).
  13. ruggerof

    ruggerof Network Guru Member

    Yes. This is what you have been doing, right? Or did I misunderstood something?

    Yes. That is what I do, well sort of, not in the router but in a persistent storage. I don't need to do anything after a reboot.

    IMHO, the good old USB stick but instead of using the Init Script you should use the "Run after Mounting". You can also try using the JFFS and the corresponding "Execute When Mounted" if you don't want to use a USB stick but I don't know if you will be forced to disable it for a firmware upgrade.

    Attached Files:

  14. ruggerof

    ruggerof Network Guru Member

    Technically yes but it would require Nazgulled some more advanced scripting skills that currently he does not have, so the easiest is the USB imho.
  15. Nazgulled

    Nazgulled Serious Server Member

    • USB: I'd rather not have a USB flash drive plugged on the router just for this purpose, feels kinda overkill. But I guess I'll resort to this option if no other solution works.

    • JFFS: Just read the documentation here and it feels like a good choice. Data on this partition is persisted and although the available space may not be much (since this is the same partition the firmware is installed) but I don't think that will be an issue for a simple cert/key file pair.

      However, firmware upgrades will require that I backup my JFFS partition and disable the option, otherwise the firmware upgrade won't be allowed.

      However, I do have a couple of questions about the JFFS partition:
      1. The link above says that I should format/erase the JFFS partition after enabling it for the first time. But it also states that this is the partition where the firmware is stored. Won't I erase the firmware if I click the format/erase button?
      2. After mounting the JFFS partition, is there a command for me to check the available space I have for my own stuff? I just want to be sure and be aware of the free space for future stuff I might need.

    • NVRAM: The setfb64 does not exist and when I ran it before, no error output was given. But my certificate was still installed and working. Which means that I simply have to replace the cert.pem and key.pem files on /etc and restart the httpd service. Even if the command existed, it was needed at all, right?

      So, can't I just store the certificate and private key as some custom nvram variables (which also persist reboots), since they are just strings, and place a script on Administration » Scripts » Init that does the following:
      1. Read certificate/key from nvram.
      2. Write those values to the corresponding files on /etc.
      3. Restart the httpd service.
      4. Profit?

    • Standard Filesystem: I guess creating some files in /root, /opt or something are not persisted through reboots so this is not even an option.
    Right now I'm trying to decide between using the JFFS or the NVRAM method I just described. If you have cons/pros of one method over the other, please let me know so I can take an informed decision.

    Yes, but I thought the nvram setfb64 command was also required for this to work. Since no warning/error was given when executing that command, I assumed it did something successfully.

    Not sure why are you assuming I don't have the required scripting skills for this...
  16. Nazgulled

    Nazgulled Serious Server Member

    Just thought about another alternative for this. Why not a simple script like this on Administration » Scripts » Init:

    cat <<-EOF >"/etc/cert.pem"
    -----END CERTIFICATE-----
    cat <<-EOF >"/etc/key.pem"
    -----END RSA PRIVATE KEY-----
    service httpd restart
    Won't this work just fine? The script is stored in NVRAM, so I don't need to worry about that. Do you see anything wrong with this approach?
  17. ruggerof

    ruggerof Network Guru Member

    An USB stick can be used for many other things, to extend functionalities via Entware, to store scripts for automation, to store log files and etc.

    I've never used JFFS because I think it is silly to have to manually back-it up if I need to upgrade the firmware, however the "df" command in Linux returns the free space in a mount. Google it if you need.

    Correct, However I *think* that you will need to read the files line by line and store each line individually in several different NVRAM variables and then reconstruct the files back.


    My bad, desculpe.

    BTW: You could also use a CIFS share to store the certificates and the script.
  18. Nazgulled

    Nazgulled Serious Server Member

    I guess it's flexible and one can do many things with it, but right now I have no need for such stuff, that's all.


    If you store a string (with newlines) and you call nvram get variable_name, you get the whole thing. Unless I'm missing something, I don't think that's an issue.

    No worries :)

    Did you check my follow up post? I just tried it and it worked just as I expected, I guess I'm going with this solution. Unless someone points a huge flaw in this approach...
  19. ruggerof

    ruggerof Network Guru Member

    Go ahead and be happy :). Glad that it worked.

    Just keep an eye in the amount of free NVRAM as you start adding things up. From my own experience I ended up having very little amount of free NVRAM fairly quick and that forced me to keep only what it is really necessary in the NVRAM. I currently even store my OpenVPN server and client certificates in my USB just to save NVRAM space.
  20. Nazgulled

    Nazgulled Serious Server Member

    I think I'm fine for now :)

    Attached Files:

  21. jerrm

    jerrm Network Guru Member

    Generally not an issue for ARM builds with 128MB or more flash. Tomato's jffs routines create a 64MB partition at the end of the flash space that shouldn't be overwritten (at least until someone creates a super-mega-firmware). I think the GUI still requires you to disable jffs before flashing, but the data should be intact after re-enabling.
  22. jerrm

    jerrm Network Guru Member

    Yes, that should be fine. Creating files from init is a very old, tried and true Tomato method. The biggest issue is timing, init is very early in the boot process. Some things in startup could come afterwards an potentially overwrite what you create. But odds are if it works once, it will always work.

    There is (or at least was) a 4K limit for the init script, so be aware of that.

    As @ruggerof says watch nvram, you basically have the cert/key pair stored twice. See my next post to eliminate that.
    Nazgulled likes this.
  23. Jacky444

    Jacky444 LI Guru Member

    This works on Advanced Tomato and should work on Tomato routers too:

    P.S.: Note that after executing commands, you have to commit to NVRAM so it saves permanently. "nvram commit" is the command to do that.
  24. jerrm

    jerrm Network Guru Member

    Final answer:

    https_crt_file is a base64 encoded version of a tar file with the key & cert. Openssl base64 decoder doesn't like it because it is not broken into 64 character lines. Luckily, the internal Tomato routines don't have a problem if the value is broken into lines.

    To store your own keys and let Tomato restore them automatically:
    nvram set https_crt_file="`tar -C / -cz etc/cert.pem etc/key.pem  | openssl enc -a`"
    nvram commit
  25. jerrm

    jerrm Network Guru Member

    base64 is not available on all builds, it may be shibby 133+, or maybe the AIO builds. I stopped at 132 vpn. Openssl should be universal.
  26. Nazgulled

    Nazgulled Serious Server Member

    I tried to reboot this once and it worked the first time. I guess I should be safe. But I'll keep this in mind.

    Glad to know that.

    I don't understand how that helps eliminate the cert/key pair duplicate storage. Should I add those commands to my init script, should I just replace the whole script with that? Can you please clarify and explain what exactly I should do?

    I'm actually using AdvancedTomato and I'm 99% sure that I followed instructions such as those and it didn't persist the reboot. And yes I did call "nvram commit". Perhaps I should use "
    nvram set https_crt_file="$(base64 /opt/tmp/cert.tgz)"" instead of the setfb64 command and this will make it persist reboots as long as "Regenerate" is UNCHECKED and "Save in NVRAM" is CHECKED?

    Just so we are all clear on this, my current build is Tomato Firmware 1.28.0000 -3.2-137 K26ARM USB AIO-64K.
  27. jerrm

    jerrm Network Guru Member

    Nothing goes into init.

    Follow the original instructions you linked to.

    But use:
    nvram set https_crt_file="`tar -C / -cz etc/cert.pem etc/key.pem  | openssl enc -a`"
    nvram commit
    Instead of the original instruction's:
    nvram setfb64 https_crt_file /tmp/cert.tgz
    nvram commit

    The key pair is then only stored once in the nvram variable Tomato uses internally.
    Nazgulled likes this.
  28. Nazgulled

    Nazgulled Serious Server Member

    Was just trying that before receiving the notification e-mail of a new reply to this thread :D

    In a nutshell, replaced /etc/cert.pem and /etc/key.pem with my own files, used the nvram commands suggested by @jerrm and rebooted (restart the httpd service if you prefer to apply changes without a reboot). PROFIT!

    Thank you everyone that contributed to this topic :)
  29. Nazgulled

    Nazgulled Serious Server Member

    Can I suggest that you update the FAQ on your website? As @jermm mentioned, the base64 is not available on all builds (it's not on mine) and his command should work regardless.
  30. Jacky444

    Jacky444 LI Guru Member

    setfb64 is not available on ARM either. While Base64 is. So this is "cross" compatible. That's why it shows on bottom if setfb64 is unavailable. People have to learn to read :D

    P.S.: I will also add OpenSSL solution =)
  31. jerrm

    jerrm Network Guru Member

    @Nazgulled 's point was that base64 is not available in all ARM builds, definitely not in Shibby <=132.
  32. Nazgulled

    Nazgulled Serious Server Member

    If you remove references to setfb64 and base64 commands and just use the recommend OpenSSL solution, that's a truly cross-build solution and it will be simpler for everyone. That's what I was suggesting, instead of adding another option to that FAQ entry and making it more confusing. But that's just me, it's your call :)
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice