1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Unable to start SSL error

Discussion in 'Tomato Firmware' started by illopel, Nov 4, 2008.

  1. illopel

    illopel Network Guru Member

    Hi,

    My setup:

    Router: WRT54GL
    Firmware: 1.21vpn1.0016 by SgtPepperKSU (thanks!!!)

    I wanted to enable https remote administration but the start of the service fails with the messages:
    Generating SSL certificate...
    Unable to start SSL

    I have cleared NVRAM variables after installing the firmware, I also set the debug level to 8, but the messages didn't contain more useful info (for me ;)).
    Does anyone have a solution how to enable remote admin access with SSL?

    Thanks,
    Till
     
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Hmmm, my VPN builds use the same version of OpenSSL as vanilla Tomato, so I don't think it could be anything I've messed up. However, could you try reflashing to regular Tomato 1.21 and see if the problem goes away? Just to eliminate extra variables/red herrings.

    If the problem does not go away, go ahead and post any log entries that show up around the same time as "Unable to start SSL". They may mean something to someone else.

    If the problem does go away, you could try updating to the latest VPN build (either 1.21vpn1.0017 or the testing version, 1.21vpn1.9036). There was a small bug in ...0016 that I don't think could cause this, but, again, we want to eliminate as many variables as possible.
     
  3. illopel

    illopel Network Guru Member

    Thanks for helping.
    Just finished my flash and configuration session. This is what I have done:

    1)
    - Flashed Tomato, version: 1.21.1515
    - Cleared NVRAM (thorough)
    - Setting back to old settings
    - Enabled remote https access -> SSL starts, access possible, no problem

    2)
    - Flashed your build 1.21vpn1.0017
    - Cleared NVRAM...
    - Settings...
    - Enabled remote https -> SSL won't start, error: Unable to start SSL

    3)
    - Flashed your test build 1.21vpn1.9036
    - Cleared NVRAM...
    - Settings...
    - Enabled remote https -> Success, it starts!

    Note, the only thing I left out in all settings was port forwarding, too much entries ;).
    I never started a vpn server (not enough time to reconfigure everything), just installed your builds and started remote access. I will see what happens if I start a server. For now I would conclude, that you eliminated the error (perhaps unintentionally ;))

    Greets,
    Till
     
  4. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Well, I'm glad it's working for you now. However, I'm kind of at a loss as to what could have caused it on the other build. Thanks for jumping through the flash hoops! At least I know it's not a problem in the latest builds.
     
  5. illopel

    illopel Network Guru Member

    Yeah, I'm glad it is working now. Problem solved...
    But I will keep an eye on it ;)

    Greetings,
    Till
     
  6. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I got to thinking about it, and, sometime before the 1.0016 release (can't remember exactly when), I messed around a little with upgrading OpenSSL. I put back the old version, but there must have been a remnant somewhere. I then moved my development environment to my laptop, building up the source tree from scratch. That would have cleared anything up that was afoul.

    So, I think the mystery is solved, and I'll be more careful in my experimenting in the future. :smile:
     
  7. ntest7

    ntest7 Network Guru Member

    I'm now having this same problem with the 1.22vpn2.0002 build. The router is a WRT54GLv1.1.

    This router previously had the official Tomato 1.22 build on it and https worked fine.

    ...
    Dec 31 16:00:08 unknown user.info init[1]: Tomato 1.22vpn2.0002
    Dec 31 16:00:08 unknown user.info init[1]: Linksys WRT54G/GS/GL
    ...
    Dec 31 16:00:08 unknown daemon.info httpd[106]: Generating SSL certificate...
    Dec 31 16:00:11 unknown daemon.warn httpd[106]: Unable to start SSL
    Dec 31 16:00:11 unknown daemon.info httpd[106]: Generating SSL certificate...
    Dec 31 16:00:12 unknown daemon.err httpd[106]: Unable to start SSL

    Any suggestions?

    What commands are used to generate the SSL certificate? Maybe I can try running them by hand.
     
  8. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I re-downloaded the build and found the same thing. Try downloading the test build 1.22vpn2.9003. I've re-downloaded it and confirmed it works.
    I'll test for this problem in all future releases and see if I can find what is causing it.
     
  9. fyellin

    fyellin LI Guru Member

    It certainly doesn't help that the ssl code just fails without giving any indication of why it is failing.
     
  10. ntest7

    ntest7 Network Guru Member

    No joy.

    I installed the v1.22vpn2.9003 version and get the same thing. I cleared nvram just for good measure; didn't help.

    I'm able to work around this by installing 1.21vpn and selecting the "save certificate in NVRAM" option, and then reinstalling 1.22vpn, but that just covers up the problem.

    Dec 31 16:00:08 unknown user.info init[1]: Tomato 1.22vpn2.9003
    Dec 31 16:00:08 unknown user.info init[1]: Linksys WRT54G/GS/GL
    Dec 31 16:00:08 unknown daemon.info httpd[106]: Generating SSL certificate...
    Dec 31 16:00:10 unknown daemon.warn httpd[106]: Unable to start SSL
    Dec 31 16:00:10 unknown daemon.info httpd[106]: Generating SSL certificate...
    Dec 31 16:00:12 unknown daemon.err httpd[106]: Unable to start SSL
     
  11. ntest7

    ntest7 Network Guru Member

    OK, this is now officially weird.

    I re-downloaded the test version just now and this time flashed the 1.22vpn2.9003/WRT54GS.bin image onto my router (rather than the "correct" GL version). This time it worked perfectly. ?!

    I then flashed using the 1.22vpn2.9003/WRT54G_WRT54GL.bin (from the fresh download) that I had trouble with before, and *it* now works fine. ????!!!!

    I don't understand what is going on here... but at least it seems to be working. I have a few other routers I'll try flashing and see what happens.

    This VPN version is so easy to setup and use. I really appreciate your work on this.
     
  12. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Well, crap. I have an idea for something to try (Tomato's libfoo.pl could be stripping out something needed), but I won't be able to until this evening. Why it seems to sporadically work, I don't know. I'll have look into how httpd uses libssl to generate the certificate and if libfoo.pl takes httpd into account.

    I'll post an update this evening when I've had a chance to try my theory.
     
  13. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    It certainly is a strange bug. I thought that it was being introduced randomly at build-time (the only changes between a build I saw breaking and a build I saw working was max certificate field length). Now, since you used the same .bin twice, and had it only work once, leads me to believe that it not the case. I had a theory I will follow up on, but just for clarification: did you use the exact same .bin file both times, or did you re-extract from the 7z archive between (or even re-download)?
     
  14. ntest7

    ntest7 Network Guru Member

    I've been experimenting with this for a few hours to try to find some consistency.

    Even using the same binary, I get different results. I've tried 2 different WRT54GL routers and a Buffalo WHR-G54S. Sometimes it works, sometimes it won't. When it won't work, it never works until a reflash. Clearing NVRAM settings doesn't seem to make any difference re the SSL problem.

    I re-downloaded the 1.22vpn2.009 build and tried again - same inconsistent behavior.

    Some additional symptoms that are have occurred on multiple routers here, but are not 100% reproducible:

    - With https enabled, after changing the router IP address, the router locks up (no http/telnet/ping, but lights look normal) until I reset defaults with the reset button.

    - when enabling https on the administration/access page, pressing the "save" button disables all admin access to the router (no http/telnet access, but it still pings and routes). A power cycle restores http/telnet access but may not allow https access still.

    Something is really unstable with the SSL on this build.
     
  15. fyellin

    fyellin LI Guru Member

    As a possibly stupid side question. What do you gain by using https instead of http when talking to the router? I suppose it does make sense when there are random users on your LAN that you don't want to oversee your conversation, or if you need verification that you really are talking to your Tomato router. Are there other advantages?

    From within my LAN, I feel safe accessing my router unencrypted because the network is encrypted (WPA/AES) and I "own" all the machines. Outside the LAN, I prefer creating an encrypted tunnel using ssh or openvpn.
     
  16. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I have the same thought process, and is why I didn't notice this until others reported it. When I want to access the admin web gui over the internet I either tunnel through ssh or VPN.
     
  17. ntest7

    ntest7 Network Guru Member

    I don't directly control all the machines on this fairly large wide-area network, and some of the routers must be accessed from outside.

    It would be nice to be able to access the web gui securely. That's sort of what https is for, and it has always worked well.
     
  18. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Okay, it seems to be something with my build environment since I upgraded my operating system. I built from the tomato source and had the same problem. I guess I'll downgrade autoconf, gcc, etc to what I had before. But, it's a little vindicating to know it wasn't something I did to the sources.

    Hopefully, I'll have everything straightened out soon and get things back on track.
     
  19. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Here is a new test build that hopefully fixes the SSL problem. Please test and let me know.

    1.22vpn2.9005

    *fingers-crossed*
     
  20. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    It looks like there have been several downloads of this test build,1.22vpn2.9005. If anyone's tried it, please report if you are seeing the SSL problem.

    If anyone else wants to test:
    • Set Web Admin Local Access to HTTP & HTTPS
    • Install test build
    • Look at system log for message about generating a certificate
    • See if it is followed by a "Unable to start SSL" message

    Thanks!
     
  21. ntest7

    ntest7 Network Guru Member

    I've been using the 1.22vpn2.9005 test build for a couple days on a couple different routers and have not had any more SSL problems. Thanks for looking at this, I know how hard it can be to fix a non-reproducible problem.
     
  22. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Since it seems to be a per-flash problem, I think if you don't see it on the first boot (if you have HTTPS enabled), then you probably won't see it at all.

    Thanks for testing and reporting your results!

    If I don't see any reports of SSL problems over the next couple of days, I'll probably make another release over the long weekend.
     
  23. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I have conclusively found the cause of this rascally bug.

    The problem is that Linksys didn't properly clean their source tree before packaging it. They have a few stray .o files along with the .c files. So, when Jon included an updated x509.c, the .c and .o didn't match.

    Normally, this doesn't cause people problems because the date on x509.o is older than x509.c and the build process rebuilds it. However, the date information was stripped in the process I used and the old x509.o was used. This version didn't include a "-set_serial" option that is used in gencert.sh to generate SSL certificates. Thus, the errors seen.

    I will go through the source and look for any more occurrences of this type of problem, and it shouldn't show up in any of my builds from now on. Thanks for you patience.
     

Share This Page