OpenVPN configuration not compatible with OpenVPN Connect 3.4.0

[Volkis]

After the latest upgrade of OpenVPN Connect (iOS) to version 3.4.0, connection fails.
When trying to connect you receive an error message; "You are using insecure hash algorithm in CA signature. Please regenerate CA with other hash algorithm".
There is a workaround by changing the advanced settings in the client software and enabling insecure authorisations.
Is there anyone that knows how to reconfigure the server settings in the ASUS router or is there an update in the queue?

 

[RMerlin]

Is there anyone that knows how to reconfigure the server settings in the ASUS router or is there an update in the queue?

Your are using certificates with a SHA1 hash. You must re-generate your certificates on the router so they switch to SHA256, then use the new generated config file with these new certificates.

 

[Volkis]

Your are using certificates with a SHA1 hash. You must re-generate your certificates on the router so they switch to SHA256, then use the new generated config file with these new certificates.

I tried to regenerate the certificate, but I can't find any settings for changing the hash level. Do I need to create a new certificate outside the system or am I just blind (the eyes are the first thing you get blind on they say)?

 

[Martinski]

I tried to regenerate the certificate, but I can't find any settings for changing the hash level. Do I need to create a new certificate outside the system or am I just blind (the eyes are the first thing you get blind on they say)?

Take a look at the following thread:

Open VPN App No Longer Working

After updating to the latest iOS Open VPN client, I can no longer connect to the server side on the Asus AX86U. I think the iOS client has updated to the newest open VPN version while the Asus Merlin server implementation is out of spec at this point. Is there a fix coming?

www.snbforums.com

When you regenerate the certificates using the "Renew" button on the WebGUI using the latest F/W versions, the correct built-in hash algorithm will be used automatically.

 

[jsbeddow]

If going to the trouble of regenerating certificates, it will also be smart to make sure to use 2048 bit RSA encryption, as 1024 bit is now deprecated and some modern OpenVPN clients will complain (force you to use "insecure/legacy" connection settings).

 

[atkinsom]

If going to the trouble of regenerating certificates, it will also be smart to make sure to use 2048 bit RSA encryption, as 1024 bit is now deprecated and some modern OpenVPN clients will complain (force you to use "insecure/legacy" connection settings).

I can’t see where to choose 2048 bit RSA in the renew section. I hit the drop down where general is located to choose advanced and nothing there either. Perhaps my old eyes are missing something. Thanks very much.

 

[ColinTaylor]

I can’t see where to choose 2048 bit RSA in the renew section. I hit the drop down where general is located to choose advanced and nothing there either. Perhaps my old eyes are missing something. Thanks very much.

The option appears when you're creating the VPN server profile the first time. It's not there when you're renewing an active profile.



EDIT: See post below about turning the VPN off and on.

 

[Martinski]

I can’t see where to choose 2048 bit RSA in the renew section. I hit the drop down where general is located to choose advanced and nothing there either. Perhaps my old eyes are missing something. Thanks very much.

To make the "1024 bit" & "2048 bit" options visible again on an already configured Server instance, toggle OFF (i.e. disable) the "Enable OpenVPN Server" setting and then click on the "Apply" button. Once that step completes, toggle the Server back ON, and you'll see the "RSA Encryption" options.

 

[HarryH3]

To make the "1024 bit" & "2048 bit" options visible again on an already configured Server instance, toggle OFF (i.e. disable) the "Enable OpenVPN Server" setting and then click on the "Apply" button. Once that step completes, toggle the Server back ON, and you'll see the "RSA Encryption" options.

That didn't happen on my RT-AC68U by just turning the VPN server off, hitting apply, and even rebooting. I had to also manually delete all of the certificate and key data, then I finally was able to see the option to select the RSA Encryption. All of that was being saved, even though I had switched off the server.

 

[bluepoint]

That didn't happen on my RT-AC68U by just turning the VPN server off, hitting apply, and even rebooting. I had to also manually delete all of the certificate and key data, then I finally was able to see the option to select the RSA Encryption. All of that was being saved, even though I had switched of the server.

What's your Openvpn server's version?

 

[HarryH3]

What's your Openvpn server's version?

Whatever came with Merlin 386.12 firmware. I see OpenVPN Server 2.6.6 in the system log.

 

[Martinski]

That didn't happen on my RT-AC68U by just turning the VPN server off, hitting apply, and even rebooting. I had to also manually delete all of the certificate and key data, then I finally was able to see the option to select the RSA Encryption.

My parents & my parents-in-law have the RT-AC68U models (1.4GHz CPU H/W revision), and I've set up the 2 OpenVPN Servers available on each router with the same configuration (except, of course, for separate port #s, IP subnets & corresponding cert & keys), but I leave only the 1st Server active/enabled while the 2nd Server is left inactive/disabled (the same way I do for my own home router).

So whenever I toggle ON the 2nd Server to activate, I always see the "1024 bit" & "2048 bit" options visible, every single time, without having to do anything to the pre-configured settings. This has been a consistent behavior over many different F/W versions through all the years that I've managed & maintained their home routers, up to the current 386.12 release.

So, while I don't doubt what you experienced, I'm wondering what's causing the behavior you described where you have to delete all certs & keys in order to finally get the "RSA Encryption" options. It's a very odd, puzzling, and not "normal" behavior, based on my experience with at least 3 separate RT-AC68U routers plus other more recent ASUS models. I also wonder if your scenario is consistent & repeatable on your particular router.

All of that was being saved, even though I had switched off the server.

Note that it's completely normal & expected that when you toggle OFF a Server instance, all its configuration settings are still saved & left intact so that later on you can simply enable/activate the Server, when needed, without having to reconfigure it all over again.

 

[RMerlin]

So, while I don't doubt what you experienced, I'm wondering what's causing the behavior you described where you have to delete all certs & keys in order to finally get the "RSA Encryption" options. It's a very odd, puzzling, and not "normal" behavior, based on my experience with at least 3 separate RT-AC68U routers plus other more recent ASUS models. I also wonder if your scenario is consistent & repeatable on your particular router.

Changing the key size does require you to generate new keys/certs, and then to share a new config file.

 

[Martinski]

Changing the key size does require you to generate new keys/certs, and then to share a new config file.

Yes, of course, there's no dispute about that; it's been made clear, AFAICT. The point is that first, you have to be able to *see* the RSA key size options (i.e. they must be visible) in order to change the current setting. If you read post #9 carefully, that's where the poster, @HarryH3, had trouble with, and his "solution" was:

"I had to also manually delete all of the certificate and key data, then I finally was able to see the option to select the RSA Encryption."

In all the years that I've managed/maintained the RT-AC68U routers, this "manual deletion of all certs & keys" has never been a required step to make the "RSA Encryption" key size options visible on the WebGUI.

 

[RMerlin]

"I had to also manually delete all of the certificate and key data, then I finally was able to see the option to select the RSA Encryption."

You can also click on the Default button at the bottom, which is more straightforward.

 

[Martinski]

You can also click on the Default button at the bottom, which is more straightforward.

Yes, that's an option if/when users need or want to reset to defaults *all* their customized, pre-configured settings of the OpenVPN Server instance so that they can start from scratch.

However, this thread here is actually about regenerating or renewing the SSL certificates of the server & client with the appropriate settings (i.e. SHA256 & 2048-bit RSA key) in order to avoid the reported errors from the iOS OpenVPN Connect app when the "Preferred" Security Level rather than the "Legacy" option is selected on the client app. AFAICT, the poster's initial intent was not to start from scratch to reconfigure all Server settings.

IMO, the suggestion to reset *all* their custom Server settings to defaults just to make visible the "1024 bit" & "2048 bit" RSA key options is misleading & disingenuous because it does not address what appears to be a problem (perhaps a bug?) where a user had to resort to manual deletion of all certs & keys from the webGUI just to make the RSA Encryption key size options visible.

 

[Tech9]

I’m good with Legacy option. Not going to reconfigure anything.

Sent from my low privacy iPhone using my highly insecure VPN.

 

[RMerlin]

IMO, the suggestion to reset *all* their custom Server settings to defaults just to make visible the "1024 bit" & "2048 bit" RSA key options is misleading & disingenuous because it does not address what appears to be a problem

The reason why it's not visible is because unlike other settings, this is not something you can change without having to reconfigure all existing clients, and cannot be reversed either if changed without understanding the consequences. This is a destructive setting, hence not available for change on an already existing setup. This is by design.

 

[RMerlin]

Another reason is that this radio toggle is not an nvram setting. It's just a temporary value that instructs the router how to initialize a NEW VPN setup. Once done, the UI no longer has any idea what key strength you are using - especially since you might have very well pasted your own 4096-bits key on the advanced page rather than using router generated keys.

 

[Martinski]

The reason why it's not visible is because unlike other settings, this is not something you can change without having to reconfigure all existing clients, and cannot be reversed either if changed without understanding the consequences. This is a destructive setting, hence not available for change on an already existing setup. This is by design.

Yes, I fully understand the reasons for the design decision to not make the RSA Key size options readily available/visible after a selection has been made & then applied; and those are valid reasons that I agree with especially because, as you said, once the user selects & applies a new key size, it's irreversible (you cannot get exactly the same certs & keys back, even if you happen to make a selection by mistake or just to see "what happens").

So I'm not questioning the design or the reasons for it. The question that eventually came up on this thread can be summed up like this: "What is the minimum number of steps necessary to make the RSA key size options visible again on an actively running OpenVPN Server instance *without* having to reset & reconfigure all other settings from scratch?"

After about 6 years of helping relatives & friends manage/maintain their ASUS routers (usually remotely via one of the built-in OpenVPN Servers), there's a simple 3-step method that I've seen working every single time:

1) Toggle OFF.
2) Click on Apply.
3) Toggle ON.

Now, when the above steps do not work on a router model that I'm very familiar with and on which I can easily double-check, my suspicion is that there's some unknown factor that's preventing the RSA key size options from becoming visible again. I don't what it is, but it's certainly not "normal" based on my experience.