The fundamental problem: GL.iNet’s script that generates security certificates uses SHA1 as a signing mechanism. This is, uh, not recommended, and hasn’t been for quite some time.
Moving forward, things (including the official Android OpenVPN client) will throw an error when you’re trying to use a certificate signed with SHA1 (and presumably MD5, but hopefully nobody has used MD5 to sign a certificate since the Clinton administration).
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
The proper solution - until it’s fixed in the official builds - is not to downgrade your security settings by ignoring the error or working around it. The solution is to generate certificates that are actually appropriate for 2023 by signing them with sha256 (or sha512) rather than sha1.
To that end, you’ll want to SSH into your router and edit:
You’ll want to change all of the instances of “sha1” to “sha256” (there are 5 of them). Arguably you should also change the 1024-bit Diffie-Hellman key to be at least 2048-bits, but I will leave that as an exercise for the reader (also, it takes a long time on said hardware, so using your pc to do it might be faster. Also the dh1024.pem keyfile is hardcoded, so just change the 1024 in the parameters, currently line 63).
Save the file.
Now go to
Delete all the files. Go back to the GL.iNet GUI, go to the OpenVPN server and you’ll see an option to generate a new configuration. Do it.
You will, of course, need to move the new configuration (or at least the certificates) to your clients. Note that this will not have any impact on VPN performance, though the certificate signing may take a little more time (Especially if you use something like 2048 bits for your dh key. Especially if you’re on older hardware.).
No more error message, and your certificates are secure! Horray!