Problems with cryptoapi / OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib

[vielhak]

Hi there,

we are using openvpn 2.5.x. Our users get a personal certificate via Intune from our internal CA with a special subject and openvpn uses 'cryptoapicert "SUBJ:intune"' to use this certificate. On some clients (all the same current Win10 version) everything works as expected. Some clients do not work (also the same current Win10 version), all with the same error message, see below

Code: Select all

2021-12-09 11:48:47 OpenVPN 2.5.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jun 17 2021
2021-12-09 11:48:47 Windows version 10.0 (Windows 10 or greater) 64bit
2021-12-09 11:48:47 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10
Enter Management Password:
2021-12-09 11:48:48 TCP/UDP: Preserving recently used remote address: [AF_INET]a.b.c.d:12000
2021-12-09 11:48:48 UDP link local (bound): [AF_INET][undef]:1194
2021-12-09 11:48:48 UDP link remote: [AF_INET]a.b.c.d:12000
2021-12-09 11:48:49 OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
2021-12-09 11:48:49 TLS_ERROR: BIO read tls_read_plaintext error
2021-12-09 11:48:49 TLS Error: TLS object -> incoming plaintext read error
2021-12-09 11:48:49 TLS Error: TLS handshake failed
2021-12-09 11:48:49 SIGUSR1[soft,tls-error] received, process restarting

The client does not send any UDP packet in this case. So I think something goes wrong while intialize the windows CNG and openssl?!
New enrollment of the user certificate on these clients did not help.
We did not find any special configurations on the clients which do not work. And if we append "tls-version-max 1.1" to the configuration all clients are working! But you will not use TLS1.1 these days...
Fresh Win10 autopilot installation via Intune and then automatic certificate enrollment and installation of the "customized" openvpn (which actually is a vanilla installation with 2 *.ovpn files) via company portal => everything works (even with TLS >=1.2). Most of the non working clients are rolled out this way, so something broke in the past!?

Any suggestions/comments are highly appreciated!

Merry XMas and best wishes for 2022!
Torsten

[TinCanTech]

Sounds like you roll-out is out-dated.

[vielhak]

Thanks... But as I wrote, some of the non-working clients aren't soooo old. There are clients which are much older installations and they are working and the winver (Win10) of all clients is the same... and why is it always working if we switch to TLS1.1?

[TinCanTech]

It works fine with TLS 1.1 because your roll-out is out-dated.

It works fine with your previously installed clients because they have old Openvpn .. etc.

[vielhak]

As I wrote ... all clients are up-to-date Windows 10 (forced with MDM and double-checked) and run OpenVPN 2.5.x (see log messages); mostly updated to 2.5.5.

[TinCanTech]

all clients are up-to-date Windows 10 (forced with MDM and double-checked) and run OpenVPN 2.5.x

2021-12-09 11:48:47 OpenVPN 2.5.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jun 17 2021
2021-12-09 11:48:47 Windows version 10.0 (Windows 10 or greater) 64bit
2021-12-09 11:48:47 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10

You can try version 2.5.5 .. maybe something got fixed.

[vielhak]

The same problem with 2.5.4 + 2.5.5.
To be precise: Clients which worked with OpenVPN <2.5.5 are still working with 2.5.5, clients which did not run with the older OpenVPN client do not connect with 2.5.5.

[becm]

The error log is a little reminiscent of similar problems with PSS padding for PKCS#11.
Restriction to TLS 1.1 disables availability/use of this padding type.
Clients up to v2.4.8 on Windows were also incapable of PSS and could do TLS 1.2 without issues.

There are however no indications why this is a problem here:
- current OpenVPN 2.5.x CNG code should support PSS padding
- for the same client version, the remote server would have to use OpenSSL 1.1.0 to not trigger PSS for TLS 1.2

A check if CNG is the culprit can be done by extracting the cert/key info and test with inline/file-based configuration.

[vielhak]

Thx. Good idea to export key/cert... but the key is marked as "not exportable"; but I think there are some tools to do it nevertheless. I will try this.