Self Signed Cert work on tomato 1.28 but not on 1.27

Scripts to manage certificates or generate config files

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Locked
rimcrazy
OpenVpn Newbie
Posts: 3
Joined: Tue May 06, 2014 9:58 pm

Self Signed Cert work on tomato 1.28 but not on 1.27

Post by rimcrazy » Tue May 06, 2014 11:12 pm

Sorry I will try to keep this short but there is a bit of background needed to understand the issue. I recently upgrade one of the 5 routers I use from an older Rosewill running Tomato 1.27 to an ASUS running Tomato 1.28. Both have the firmware configured to run VPN servers. I also took this opportunity to upgrade all of my clients from OpenVPN 2.2.2 to version 2.3.4 as well as cut all new keys for everything.

To generate the keys I am using easy-rsa on a CentOS 6.5 linux server that has the latest versions of OpenVPN and easy-rsa. I am creating self signed certificates. I created new keys for all of my routers so I have 5 routers, one of which is a new ASUS running 1.28 and 4 Rosewill's running 1.27.

The new keys work fine on the ASUS router. Everything connects and everything works. On the Rosewill's however there seems to be an issue where the connection fails. I am getting certificate issues -> SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

My first assumption is I have a typo somewhere and/or made the keys wrong or did not get them signed right. I redid everything, twice. No such luck. What is interesting is the key set that I generated for the ASUS is working. So I took that key set and put it on one of the Rosewill's and I get the error message above. I then went back looking at my old keys that work on the Rosewills and found that there is a difference in the client signature certificate algorithm. The keys that work use :

Signature Algorithm: md5WithRSAEncryption

while the keys that do not work use:

Signature Algorithm: sha256WithRSAEncryption

This is about the only difference I can see. So my question is, is there a way to generate keys with easy-rsa and have it use md5 instead of sha256 in creating the client .crt files? (I did look through the scripts as best as I could but I did not see anything directly related to that.)

Any assistance would be greatly appreciated.

Quick Note: I was looking to see if I couldn't just use OpenVPN 2.2.2 to create older keys but for some reason that distribution of easy-rsa keeps puking as it is looking for an openssl directory at the c: level and when I installed OpenVPN 2.2.2 it does not create a directory there.

rimcrazy
OpenVpn Newbie
Posts: 3
Joined: Tue May 06, 2014 9:58 pm

Re: Self Signed Cert work on tomato 1.28 but not on 1.27

Post by rimcrazy » Wed May 07, 2014 12:44 am

Thanks. I suspect it is not a hardware issue but something subtle between the versions of Tomato 1.27 and 1.28. The obvious answer might be just reburn the routers to the newer version. The complication there is that the other 4 are physically spread all over the state and reburning, while still a very valid option, is a semi-major PITA I would prefer not to do if I can find an alternate route. Your solution to just rekeying with the older version of OpenVPN/easy-rsa would be a much simpler solution if I can get it to work. I will look into that.

rimcrazy
OpenVpn Newbie
Posts: 3
Joined: Tue May 06, 2014 9:58 pm

Re: Self Signed Cert work on tomato 1.28 but not on 1.27

Post by rimcrazy » Wed May 07, 2014 4:15 pm

I thought I would post a final reply to at least help someone else out who may be having the same issue. While I can't confirm that tomato 1.27 is the real issue I suspect that it probably is. I downloaded OpenVPN 2.2.2 for Windows and put it on my machine. As noted you have to make not one but two edits to get things to work.

1) Create a directory c:\openssl\ssl and the copy the openssl.cnf file from the easy-rsa folder into this location.
2) Edit the clean-all.bat file and add the following line to the bottom

echo unique_subject = no >%d%\index.txt.attr

This will remove the "TXT_DB error number 2". You need to run clean-all before each key generation sequence. Doing both of these (and don't forget to edit vars to your configuration setup) I was able to generate a set of keys that works on my routers. Most likely as these get old and get replaced I will upgrade the firmware but for the moment this is a solution that work.

Locked