Plans to migrate to OpenSSL 3.0?

[Martinski]

Update
With the new Openvpn connect App V3.4.0 and set security level to "preferred", I got this.
View attachment 53650
I have to choose "Legacy" to successfully connect to the server.

View attachment 53651

It's less secure for now but it's fine until asus updates to Openssl 3.

To use the "Preferred" option in the "Advanced Settings" section of the OpenVPN Connect client app, you must have at minimum a 2048-bit RSA key in your OpenVPN Server configuration, which you can do yourself. You don't need to wait for ASUS to upgrade OpenSSL in the router F/W.

 

[bluepoint]

To use the "Preferred" option in the "Advanced Settings" section of the OpenVPN Connect client app, you must have at minimum a 2048-bit RSA key in your OpenVPN Server configuration, which you can do yourself. You don't need to wait for ASUS to upgrade OpenSSL in the router F/W.

It does not work even if 2048-bit RSA key is configured. I'll try to export a new config with 2048-bit enabled if that makes a difference?

Update:
New config with 2048-bit key didn't work either.

 

[Martinski]

It does not work even if 2048-bit RSA key is configured. I'll try to export a new config with 2048-bit enabled if that makes a difference?

Update:
New config with 2048-bit key didn't work either.

If the newly generated & imported OpenVPN client config file still doesn't work with the "Preferred" option, you need to check each & every error message that you get and fix them one at a time. It's essentially a matter of having the OpenVPN Server configuration options satisfy the minimum set of requirements that the updated OpenVPN Connect client app considers "secure" based on its current cryptographic standards.

For example, make sure your Diffie–Hellman (DH) key exchange was also regenerated using a 2048-bit key. The file should have today's time/date stamp if the DH key was regenerated:

ls  -l  /jffs/openvpn/vpn_crt_server*_dh

Also, if your OpenVPN Server is currently using what the client app now considers weak & outdated encryption algorithms (i.e. "Legacy" options) you'll need to fix those in your server configuration as well.

EDIT:
BTW, make sure the OpenVPN Server is restarted after making any config changes:

/sbin/service restart_vpnserverX

Where "X" is the server number: 1 or 2.

FYI, my OpenVPN Server works fine when I use the "Preferred" option; I didn't have to change anything in its configuration after the client app was recently updated on my iPad.

 

[bluepoint]

How do I know if my DH key is 2048 bit?
ASUSWRT-Merlin GT-AX6000 3004.388.4_0 Mon Aug 21 19:34:19 UTC 2023
gxxxxxx@GT-AX6000:/tmp/home/root# ls -l /jffs/openvpn/vpn_crt_server*_dh
-rw------- 1 gxxxxxx root 424 Oct 14 15:44 /jffs/openvpn/vpn_crt_server1_dh

 

[Martinski]

How do I know if my DH key is 2048 bit?
ASUSWRT-Merlin GT-AX6000 3004.388.4_0 Mon Aug 21 19:34:19 UTC 2023
gxxxxxx@GT-AX6000:/tmp/home/root# ls -l /jffs/openvpn/vpn_crt_server*_dh
-rw------- 1 gxxxxxx root 424 Oct 14 15:44 /jffs/openvpn/vpn_crt_server1_dh

Use the following command:

openssl dhparam  -in /jffs/openvpn/vpn_crt_serverX_dh -text | grep "DH Parameters:"

Where "X" is the server number: 1 or 2.

 

[bluepoint]

Use the following command:

openssl dhparam  -in /jffs/openvpn/vpn_crt_serverX_dh -text | grep "DH Parameters:"

Where "X" is the server number: 1 or 2.

Ok, I'm good.
gxxxxxx@GT-AX6000:/tmp/home/root# openssl dhparam -in /jffs/openvpn/vpn_crt_server1_dh -text | grep "DH Parameters:"
DH Parameters: (2048 bit)

Let me show you my config maybe you'll see where I can correct. Are you on iOSPad 17?

 

[bluepoint]

Here's what I get from Bing chatgpt it seems to suggest the same 2048 bit key as the minimum SSL certificate.

opensslcontext:ssl_ctx_use_certificate failed:error:0a00018f:ssl routines::ee key too small
Searching for: opensslcontext:ssl_ctx_use_certificate failed:error:0a00018f:ssl routines::ee key too small
Generating answers for you…
Generating answers for you…
The error message you are seeing is related to the SSL certificate being used. The error message “opensslcontext:ssl_ctx_use_certificate failed:error:0a00018f:ssl routines::ee key too small” indicates that the SSL certificate being used has a key that is too small. This error can occur when the key size of the SSL certificate is less than 2048 bits, which is the minimum recommended key size for SSL certificates 123.
To resolve this issue, you can regenerate your SSL certificate with a larger key size. You can use the following command to generate a new SSL certificate with a 2048-bit key:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

Copy
This command will generate a new SSL certificate with a 2048-bit key and a validity of 365 days. You can then use this new SSL certificate in your application.
I hope this helps!

 

[Martinski]

Ok, I'm good.
gxxxxxx@GT-AX6000:/tmp/home/root# openssl dhparam -in /jffs/openvpn/vpn_crt_server1_dh -text | grep "DH Parameters:"
DH Parameters: (2048 bit)

Let me show you my config maybe you'll see where I can correct. Are you on iOSPad 17?

I suggest you provide a screenshot of whatever error(s) you're getting now. If both the RSA & DH keys are now 2048 bits then the error should be different from your previous screenshot, and should point to something else that it's now considered "insecure" when running the updated app in "Preferred" settings mode.

iPadOS 17.0.3 version.
OpenVPN Connect 3.4.0 (5457) version.

Also (again), double-check that the OpenVPN Server is restarted after making any config changes:

/sbin/service restart_vpnserver1

I'll take a look at your Server config, but a screenshot of the client error message would help narrow down the possible cause(s).

 

[Martinski]

...
opensslcontext:ssl_ctx_use_certificate failed:error:0a00018f:ssl routines::ee key too small
Searching for: opensslcontext:ssl_ctx_use_certificate failed:error:0a00018f:ssl routines::ee key too small
Generating answers for you…
Generating answers for you…
The error message you are seeing is related to the SSL certificate being used. The error message “opensslcontext:ssl_ctx_use_certificate failed:error:0a00018f:ssl routines::ee key too small” indicates that the SSL certificate being used has a key that is too small. This error can occur when the key size of the SSL certificate is less than 2048 bits, which is the minimum recommended key size for SSL certificates 123.
To resolve this issue, you can regenerate your SSL certificate with a larger key size. You can use the following command to generate a new SSL certificate with a 2048-bit key:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

Double-check the current CA certificate used by your server with the following command:

openssl x509 -noout -text -in "/jffs/openvpn/vpn_crt_server1_ca" | grep -E "Signature Algorithm:|Public Key Algorithm:|RSA Public-Key:"

EDIT:
Your output should match the one shown below from my router:

If not, you must regenerate the certs by clicking on the "Renew" button on the router's WebGUI, and then export the client config file for all your devices that connect to your server.

 

[bluepoint]

Double-check the current CA certificate used by your server with the following command:

openssl x509 -noout -text -in "/jffs/openvpn/vpn_crt_server1_ca" | grep -E "Signature Algorithm:|Public Key Algorithm:|RSA Public-Key:"

That's it, apparently, when I generated the CA certificate my RSA encryption was set to 1024 bit so the CA certificate follows. Once I set the encryption to 2048 bit then regenerated the CA certificate, it created the proper 2048 bit CA. Now it works with "preferred" option. Thank you much sir!

gxxxxxx@GT-AX6000/tmp/home/root# openssl x509 -noout -text -in "/jffs/openvpn/vpn_crt_server1_ca" | grep -E "Signature Algorithm:|Public Key Algorithm:|RSA Public-Key:"
        Signature Algorithm: sha256WithRSAEncryption
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
    Signature Algorithm: sha256WithRSAEncryption

 

[RMerlin]

It's less secure for now but it's fine until asus updates to Openssl 3.

Asus updating to OpenSSL 3.0 will NOT fix your issue. The issue is your keys and certificates were generated with an older algorithm, you have to re-generate them.

The issue is not the version of OpenSSL used by the router, it's the keysize/hash used by your certificates.

 

[bluepoint]

The issue is not the version of OpenSSL used by the router, it's the keysize/hash used by your certificates.

Yes, that's what I found out from @Martinski and now works after I corrected keys/hashes sizes. This dumb guy learned something from this.

 

[jsbeddow]

This is a bit of a drag to learn that even a relatively "recent" set of OpenVPN certificates and keys, generated in April of this year (using 384.2 firmware), still uses "only" 1024 bit encryption, rather than the current standard of 2048 bit encryption.

Not sure if I want to go through the hassle of again regenerating keys/certs and distributing them to all my client devices again. I may wait to see if I start seeing the devices complain about the settings as the client side apps get updated.

 

[bluepoint]

This is a bit of a drag to learn that even a relatively "recent" set of OpenVPN certificates and keys, generated in April of this year (using 384.2 firmware), still uses "only" 1024 bit encryption, rather than the current standard of 2048 bit encryption.

In fairness, there were choices, like in my case, I chose 1024 bit RSA instead of 2048 bit when I first setup the server knowing nothing about the consequences in the future. My assumption was that 1024 bit will be faster and secure enough so I choose.

Not sure if I want to go through the hassle of again regenerating keys/certs and distributing them to all my client devices again. I may wait to see if I start seeing the devices complain about the settings as the client side apps get updated.

I'm afraid you might have no choice in the future as newer clients/servers requires 2048 bit CA/encryption as minimum but for now you'll be fine not unless 1024 bit encryption is no longer safe.

 

[jsbeddow]

In fairness, there were choices, like in my case, I chose 1024 bit RSA instead of 2048 bit when I first setup the server knowing nothing about the consequences in the future. My assumption was that 1024 bit will be faster and secure enough so I choose.


I'm afraid you might have no choice in the future as newer clients/servers requires 2048 bit CA/encryption as minimum but for now you'll be fine not unless 1024 bit encryption is no longer safe.

It's funny, but I don’t remember making that conscious choice of 1024 or 2048 bit encryption when setting it up, but I'll take your word for it, as the firmware GUI doesn't expose those settings, presumably until you are actually renewing or setting things up for the first time (ie. -they aren't visible when reviewing current settings).

 

[Martinski]

In fairness, there were choices, like in my case, I chose 1024 bit RSA instead of 2048 bit when I first setup the server knowing nothing about the consequences in the future. My assumption was that 1024 bit will be faster and secure enough so I choose.


I'm afraid you might have no choice in the future as newer clients/servers requires 2048 bit CA/encryption as minimum but for now you'll be fine not unless 1024 bit encryption is no longer safe.

IMO, using 1024-bit RSA encryption keys can be considered safe enough for now *if* all you're protecting is access to the router's Admin WebGUI, primarily because that kind of VPN traffic is transient and limited to your own household. So unless you're a famous celebrity, corporate executive officer, political activist/dissident in an "unfriendly country," influential person in politics, economics, military, intelligence agent, etc., or someone that expects to be a target of nation-state sponsored cyberattacks/espionage, I would not worry about using 1024-bit RSA encryption with your home router's OpenVPN server, at least for now and for the near future (~2-4 years perhaps, depending on whose estimates you believe when such RSA key will be easily cracked as raw computing power increases).

However, if you're trying to protect more sensitive personally identifiable information (e.g. banking/financial/medical records, passport, driver's license, ID card, social security number, etc.), or perhaps some corporate proprietary info or intellectual properties that you have access to, then yes, the minimum recommendation is now 2048-bit encryption keys, with 4096-bit keys as ideal (and I likely would not be using an AIO ASUS home router).

Note that when using 1024-bit keys, there are a couple of options that you can use to make your OpenVPN traffic just a little bit more secure at the cost of some performance:

1) Set "HMAC Authentication" option to at least "SHA 256"
2) Set "TLS control channel security" option to "Encrypt channel"

This way, every TLS control channel packet is signed with an HMAC signature and encrypted, even during the initial multi-packet exchange/handshake that happens before client authentication is established.

The bottom line is that only you know what you're trying to protect & how valuable it is to you, so ultimately it comes down to a personal decision about how "secure" you want to make it.

Just my 2 cents.

 

[bluepoint]

It's funny, but I don’t remember making that conscious choice of 1024 or 2048 bit encryption when setting it up, but I'll take your word for it, as the firmware GUI doesn't expose those settings, presumably until you are actually renewing or setting things up for the first time (ie. -they aren't visible when reviewing current settings).

Toggle the Openvpn server off/apply from the GUI then turn it on. Once it comes up the choices for 1024 bit and 2048 bit encryptions will be visible. Remember once you made the change to 2048 bit encryption you have to regenerate your certificate.