V1.21 with openvpn and IPCOP (openvpn ZERINA-0.9.7a14) CA too long ?

Discussion in 'Tomato Firmware' started by wege, Oct 17, 2008.

  1. wege

    wege Addicted to LI Member

    Hello :),

    I'm new to this forum and the first thing I've to say is that I'm very impressed :thumbup: by the tomato firmware. I recently installed tomato V1.21vpn0087 (thx to SgtPepperKSU) on a WRT54GL. All went smooth and now I'm trying to make a net2net tunnel to our company (with modified ipcop 1.4.11 + zerina-0.9.7a14) via openvpn.

    The ipcop is the vpn-server. I've generated the keys on the ipcop and added a net2net connection. By adding the net2net connection the zerina package generates a client certificate in pkcs12 format.

    As of now it is not possible to use this generated key directly as the tomato-openvpn uses (TLS --cert or static keys). So I've converted the xxxxxx.p12 file with the following commands on the ipcop machine.
    openssl pkcs12 -clcerts -nokeys -in wgh.p12 -out wgh.crt
    openssl pkcs12 -cacerts -nokeys -in wgh.p12 -out wgh.ca
    openssl pkcs12 -nocerts -in wgh.p12 -out wgh.key
    openssl rsa -in wgh.key -out wgh.nokey
    If I try to paste the server certificate into the WEB-Gui I get the message:
    "Invalid length try to reduce the length to 1296 characters or less"

    How do I accomplish that ? What am I doing wrong :confused:?

    The other generated keys/certificates seems to be ok.

    @SgtPepperKSU: Is it possible to add direct pkcs12 support?

    thanks in advance, wege
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Does the data you are trying to paste have a lot of header information before the "-----BEGIN CERTIFICATE-----"? If so, you can delete all of it. If not, I just didn't make the field long enough to use that type of key. How many characters long is it? (you can use echo "<paste here>" | wc -c to count it for you on a unix-like system - like the router ssh shell).

    And to answer your question about direct pkcs12 support: My understanding (I've never used pkcs12) is that it is a binary file. That would be difficult to enter using a web GUI.
    I guess I could add a "custom" option to let you specify that information in the Custom Configuration section (pkcs12 <path-to-file>). You would then be on your own to get the pkcs12 credentials on to router and putting it on a cifs or jffs2 mount to persist it. That would be very doable if that would be acceptable.
  3. wege

    wege Addicted to LI Member

    Thanks for your fast respone. The file has 1333 characters whithout header and footer. If you could make the field longer that would probably do the trick.

    I also never userd pkcs12 files before (all tunneling before was done with ipsec ond psk, rsa-keys). You are right, pkcs12 files are binary files. With the zerina ipcop extension this file will be generated and also a client configuration (client package). So it is possible to dowload the pkcs12 file + the configuration to a windows client and make the tunnel with openvpn. I've tried to paste the configuration to the custom configuration field but then I will get an error because of --cert and pkcs12 wgh.p12 (the pkcs12 file) are in conflict.

    Generated ipcop/zerina configuration:
    dev tun
    tun-mtu 1400
    proto udp
    port 1195
    remote xxx.xxx.xxx.xxx
    pkcs12 wgh.p12
    keepalive 10 60
    cipher BF-CBC
    verb 3

    So I think you are the second time 100% right to add a custom option :).

    If you could make above changes I will be the first who will test this ;) ... thanks

    The only question is what to do with overlapping information - I think custom config options should get higher priority.
    An other possibility would be an input field for a pkcs12 file and than start the vpn without --cert.
    Custon config could than mean full custom config (from custom input field).
  4. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The problem with having an input for your pkcs12 file is that I would have to have somewhere to store it. The only place I can count on to survive a reboot is NVRAM, which isn't suitable for binary data by itself. I think it's a fair compromise that you would need to set up a jffs2 mount (Look under administration->jffs2) and get the pkcs12 file there on your own. Then you'd just point to it with "pkcs12 /jffs2/wgh.p12" in the Custom Configuration section.

    What I was envisioning was when "Custom" was selected for encryption type, I would not generate any tls-(client|server), cert, key, ca, dh, etc entries. But, I would still generate the rest. Then you would just need to add the pkcs12 and tls-client lines. I hadn't thought of adding a completely custom option (where there are no auto-generated lines at all). Seems to me it kind of defeats the purpose of using the GUI. I'll think about it, though.

    I should also probably be generating that route line you have for tun-type connections, or at least have an option to (for now you can paste it into the custom section).

    As for overlapping information, I don't think I should be getting into the business of parsing and understanding what is entered in the Custom Configuration section (there are just way too many options). It is just appended to the end after auto-generating the rest.
  5. azeari

    azeari LI Guru Member

    i dump my certs into jffs (= bypasses the problem
  6. wege

    wege Addicted to LI Member

    To store the pkcs2 file onto jffs2 filesystem and to add a line in the custom configuration section is not really a problem. For my personal problem the easyiest solution is to get the converted "server ca" loaded into the input field and hopefully get the tunnel to work. You are right, parsing doesn't make really sense.
    So can't await your changes ;) ...
  7. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Yah, that's exactly what I was suggesting the user would have to do. But, I don't think the GUI should assume that JFFS is properly setup and enabled, so it can't do that automatically...
  8. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I think in the meantime, you should be able to ssh in to the router and run the following from the shell:
    nvram set vpn_client1_ca="PASTE_CONTENTS"
    of course replacing PASTE_CONTENTS with the contents of your ca file. That bypasses the length checking. The only problem is that if you want to make further changes on that page, it will complain about that field being too long again. So, just make sure you get everything else set up then run that command from the shell. Then you should be able to get running :smile:
  9. wege

    wege Addicted to LI Member

    I've read over the thread again and I misunderstood that the certificate also needs to have a header and footer.
    -----END CERTIFICATE-----
    does have 1635 bytes.
  10. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    It does need to have the ----...CERTIFICATE---- parts, but not anything before (I know OpenVPN generated certificates have a bunch of human readable stuff above it that doesn't need to be put on the router).

    Before you said 1333, now 1635. The ----...CERTIFICATE---- lines don't account for that difference. I just want to be sure: what is the length including the ----...CERTIFICATE---- lines and everything inbetween, but nothing else?
  11. wege

    wege Addicted to LI Member

    Thanks for your instant hack on how to set that values by hand - I also had to do it with client cert (also too short - needs 1387 bytes for me).

    YES - It works !!!!

    (alltough I had to set "float" on the client configuration on the ipcop and setting a net route to our company net over device tun11)
  12. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Good to hear! In light of you being operational, I'm going to try to get the site-to-site via TAP straightened out (this weekend? *fingers-crossed*) before releasing another build. Then you will be able to use your pkcs12 file or input your certificates through the GUI.
  13. wege

    wege Addicted to LI Member

    Including ---- BEGIN/END CERTIFICATE ----
    Certifate Authority: 1635 bytes !
    Client Certificate: 1387 bytes !
    Client Key: 887 bytes

    PS: I also will cross my fingers - good "luck" ;) ... thx
  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