What's new

N66U + frmw 3.0.0.4.378_4850 + VERIFY ERROR: depth=0, error=unsupported certificate

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

netfortius

Occasional Visitor
Story:

- last *official* firmware from Asus on the n66u (376_3861) => ok with android openvpn clients, not ok on tunnelblick (OSX), due to too short DH

- $ sudo openssl dhparam -out dhparams.pem 2048 - followed by copying the content of dhparams.pem to the appropriate field (DH) in the router - save - fixed the DH error, but ended up with padded extra characters by the admin UI, for all cert content (files), which now fail client conn because of that

- upgraded to the beta version (378_4850), supposed to fix the padding (?? - should I get the japanese version 378_7410, instead?) => now the ca file only contains an extra line for each line of content, when exporting it to the client.ovpn AND - even if manually correcting by removing the empty lines - produces the following error on tunnelblick client connect:

"VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=TW, ST=TW, L=Taipei, O=ASUS, CN=client, emailAddress=me@myhost.mydomain
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"

Question: has anybody successfully got the openvpn server install from asus n66u running with tunnelblick client, or is this just not feasible? If successful - how?

Related Q: assuming that "toying around" with the various cert files I succeeded in breaking something, what is the alternative (short of factory reset???) to get back to the "out of the box" configuration of openvpn?
 
Posting progress on the above issue: having saved the client.ovpn from the previous (original) config, I compared it with the newly produced one (let's call it client-new.ovpn) - via diff, and the <ca> ... </ca> block in one is reported being different than the other. Running md5 against both files produces different results, also. So they are different. But how? And here come the mind boggling issue:

- opening the files in various editors, to reveal some control characters in one vs the other, reveal nothing
- copying the diff block reported to not being identical (the <ca>...</ca> one), from the "good, old" client.ovpn, and pasting it into the appropriate field (ca) on the OpenVPN file config web UI, then re-exporting the new client ovpn produces a file different than the original (!!)

Any ideas here ???

BTW - upgraded to the latest of latest version (the alleged Japanese version) - 378_7410 - still same problem.
 
Last edited:
I'm not sure what the official firmware is using in terms of the OpenVPN server and OpenSSL, but the issue you're likely having is due to updates to OpenSSL used by Tunnelblick in newer versions that requires a minimum of 1024-bit DH key. You can always use a deprecated version of Tunnelblick as a work around, or you'll have to generate a new 1024-bit key. Not sure how that's done exactly, but the 378.55 Merlin version has a 1024-bit version available.
 
Already had the 2048 DH created. Fixed the issue in a more aggressive way: wiped clean the jffs location of all files, and recreated them. Problem solved.

Sent from my Nexus 7 using Tapatalk
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top