Inheriting existing setup, new certs don't work

[PhilK]

I've inherited an existing, working OpenVPN setup. The server is a router running DD-WRT. Using existing certs, clients connect fine. (Have used both 2.1.4 and 2.2.0 clients)

I need to create some additional certs for new clients, and the certs I create aren't working. The error log (Windows 7 in this case) shows a generic TLS error:

"TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)"
"TLS Error: TLS handshake failed"

On the same client it works fine when I use one of the original certs.

I originally ran into the easy-rsa bug on 2.2.0 (https://community.openvpn.net/openvpn/ticket/125)

So I copied the easy-rsa folder from one of the older clients running 2.2-beta3 (I believe this was the version used to create the original CA), copied the original certs, keys, index files, PEM files, CSRs into the key folder and proceeded to create new client certs.

The only thing changed (that I know of) from the original CA configuration is I renamed the CA.crt and CA.key files because the original names were confusing. (There are multiple CA's and I don't want a bunch of like-named files) I changed the requisite sections of openssl.cnf to match the new names. I also added the recommended sections under [server] recommended in the bug report linked above.

Can someone tell me how to determine what part of the TLS negotiation is causing this error? TIA...

[janjust]

the openvpn server log will show the true error of the failed handshake - please post the server log when the failing client tries to connect; make sure the old ca.{crt,key} files are indeed the same as the new ones - it is possible to use multiple CA certs in one server installation, but this requires an extra step.

[PhilK]

Thanks Jan. I'll try to get the server logs, unfortunately that box (silly Linksys thing running DD-WRT) is refusing my SSH login at the moment..

[janjust]

another thing to post is the names of each ca.crt file on both client and server - the client needs the ca.crt from the CA that signed the server cert; the server needs the ca.crt from the CA that signed the client cert (if they are different).

If you have multiple CAs you can find out info using

Code: Select all

openssl x509 -text -noout -in ca.crt

this is public information (perhaps you want to block out any email addresses) so your PKI won't be compromised if you post this info.

[PhilK]

Yep, I'm generally fairly paranoid about posting site-identifiable stuff and will generally change it to something that doesn't change the meaning of the data unless there's a compelling reason not to.

As for the multiple CA's, I inherited this system from someone who created the original CA's, so I don't have access to every single bit, but I do have all the original certs/keys/pems/etc.

I'm keeping the CA's separate by just making copies of the entire easy-rsa folder for each CA, and adapting the openssl.cnf file with the custom path in each case.

There are just 2 existing CA's, one for "site A" and one for "site B". So for clients that need to connect to site A, I have a "CA A" folder and create client certs there, and for clients that need to connect to site B, I have a "CA B" folder (not yet populated) and create the client certs there.

There's something about the certs I'm creating that the existing servers (under DD-WRT) don't like, even though I'm trying to specify the same parameters for C=/O=/OU=/email address= as the original certs. Maybe the newer version of openssl has an idiosyncracy in how it creates certs that the version running on the server(s) doesn't like?

Going to try to get those logfiles in the next couple of hours or so. Thanks for the help so far.

[PhilK]

BTW - is it important to keep the names of the certs the same as when the server was setup? Maybe that's the issue?

I didn't like the idea of having multiple "ca.crt" files that I couldn't identify which CA it belonged to, so I changed the name of ca.crt and ca.key for "CA A", and changed the references in openssl.cnf for that instance. Is that what's killing me?

Edit: That means the copies in my new "CA folder" I'm using to create client certs, not the ones on the active server(s).

[janjust]

don't use spaces in the filenames; and if you're using multiple CA's then you also need multiple 'easy-rsa' (at the very least .../keys) directories.

[janjust]

as an extra note: no the names of the CA certs does not need to be kept the same; if the setup was created using 'easy-rsa' then it is the easiest to keep the separate CA + client keys in their separate directory structures; the 'easy-rsa' scripts use the 'openssl ca' command, which is based on a 'keys' directory.

[PhilK]

Since I've now seen several cases where the certs I created didn't work initially but worked later, I've concluded that the most likely reason is some sort of clock sync or timezone issue between the PC where I am creating the certs and the OpenVPN server.

I don't have any proof of that, but that seems the most likely explanation right now.

BTW - the DD-WRT device hosting the server side looks like it's supposed to have a log link for OpenVPN in the UI but for some reason there is no active link there. Tried logging in via BusyBox but there's not even an ls command available in that shell so I can try to manually locate the logfiles. Hard to troubleshoot when I can't read the logs..

Thanks for your suggestions Jan, much appreciated.

[janjust]

Since I've now seen several cases where the certs I created didn't work initially but worked later, I've concluded that the most likely reason is some sort of clock sync or timezone issue between the PC where I am creating the certs and the OpenVPN server.

this is very well possible - certificates are checked for validity using UTC times ; if the clock of the PC where you created is not in sync with UTC (i.e. local time may be correct, but due to timezone differences UTC time is off) then you'd see such an issue.