OpenVPN server "weak hash" on Mango

Trying to configure OpenVPN server on Mango to work with OpenVPN for Android (TV) app.
However, when I import the profile and try to connect I get errors (below) and it won’t connect.

Warning: No server certificate verification method has been enabled.
OpenSSL: error:0A00018E:SSL routines:ca md too weak
MGMT: Got unrecognized command>FATAL:Cannot load inline certificate file
OpenSSL reported a certificate with a weak hash
(similar to this post: Meet Brume 2! - #92 by lostdog)

Also importing the same OVPN file in the windows OpenVPN Connect app I get
Error Message: Peer certificate verification failure.

So, just would like to know what is wrong with the OpenVPN server configuration?
Mango is running FW 3.215 which is the latest.

OpenVPN on the Mango and other GL.iNet routers uses an older version of the openvpn-openssl package, probably 2.5.3 that you can look up in Admin Panel → APPLICATIONS → Plug-Ins.

OpenVPN for Android uses OpenSSL 3.0 and rejects the older version by default. You can try a workaround by editing that profile in the app:

Go to ADVANCED → Custom Options
Add the line:

tls-cipher “DEFAULT:@SECLEVEL=0”

Save the change and connect again

I had this problem during testing of Brume 2, where the offiicial latest OpenVPN Connect app by openvpn.net with OpenSSL 1.1.1 worked and the latest OpenVPN for Android app did not work. When I used the workaround in the OpenVPN for Android app, then it connected successfully.

Note that OpenSSL 1.1.1 is still on long term support until September 11, 2023, so GL.iNet needs to upgrade their firmware by that date.

I do not work for and I do not have formal association with GL.iNet

This has nothing to do with that. This has everything to do with the fact that SHA1 hasn’t been secure to sign certificates for going on about a decade now. (And for some unexplainable reason the script that gl-inet uses to generate the certificates uses SHA1).

I know @wcs2228 won’t see this because reasons, but recommending people to downgrade security settings rather than fixing the underlying problem is, in my opinion, just super poor form.

What you need to do is regenerate the certificates used for the VPN so that it’s actually secure, as opposed to, well, not.

Change the /usr/bin/cert_manager and replace all instances of sha1 with sha256. Then generate new certs.

(paging @alzhao to this thread because it’s going to continue to be a problem until it’s fixed)

1 Like

I have notified guys to fix.

Thanks for the suggestion, this is a bit beyond what I can do unless there is a step by step how to.

I guess this may be fixed soon with a firmware upgrade now that dev team is aware?

Happy holidays!!

This is a more detailed guide but may not have enough info. Are you familiar with using ssh to access the router, either using command prompt or PuTTY (or terminal on a Mac)? That’s the first step, then you’ll need to use a text editor (vi is my editor of choice, but the interface is… Not good)? If you can get into it via ssh, I can write a one line sed command for you that will make the appropriate changes.

@alzhao, when do you think there will be fixes released for all the affected GL.iNet routers (maybe all of them)? I checked that all my 5 routers with Firmware 3 and FIrmware 4 are affected.

@hansome is on this.

Should users stop using OpenVPN server on their routers until after they have fixes?

Some VPN is better than no VPN. But you should fix it asap.

This has been fixed and will be in next snapshot or beta.

Are the fixes for all affected GL.iNet routers?

Yes. It will be on 3.216

Routers with Firmware 4 are also affected (at least GL-A1300 and GL-MT2500).

Yes. The fix is For both 3.x and 4.x firmware.