Re: [Openvpn-users] Problem with Athena signed rsa pkcs

[Carsten M. <Car...@at...>]

Hi Selva,

Thank you very much for your support. Your solution works great.

Charly

Von: Selva Nair <sel...@gm...>
Gesendet: Donnerstag, 27. November 2025 19:49
An: Carsten Mietzsch <Car...@at...>
Cc: ope...@li...; Wilhelm Greiner <Wil...@at...>
Betreff: Re: [Openvpn-users] Problem with Athena signed rsa pkcs

Hi,

> I suspect that the stick simply does not support pss, but we are also unable to get the server to accept the old procedure. The signature algorithm is sha256RSA.
 > Unfortunately, over 1000 tokens are already in the field and a worldwide replacement is difficult.

If the stick does not support PSS, you would normally get an error on the client --- we set the mechanism to CKM_RSS_PKCS_PSS before calling the sign routine in pkcs11-helper. A well behaved token would error out if it gets a signature request with an unsupported mechanism.

OpenSSL3.0 prioritizes PSS signatures even for TLS 1.2 but it's not mandatory (unlike TLS1.3). So, if you want to avoid using PSS, you can restrict the signature algorithms in openssl.cnf (doing this only on client or server side should be enough). Here is a snippet of "/etc/ssl/openssl.cnf" showing this:

openssl_conf = default_conf



[default_conf]

ssl_conf = ssl_sect



[ssl_sect]

system_default = system_default_sect



[system_default_sect]

SignatureAlgorithms = RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512

# add more algorithms if required

Selva

On Thu, Nov 27, 2025 at 7:09 AM Carsten Mietzsch via Openvpn-users <ope...@li...<mailto:ope...@li...>> wrote:
Hi,

We use Athena IDProtect tokens on the client side for pkcs#11 authentication. While the client does not display any errors during the handshake via pkcs, we receive a rejection on the server side:

2025-11-27T08:31:26.281152+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> Sent fatal SSL alert: decrypt error
2025-11-27T08:31:26.281207+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> OpenSSL: error:02000068:rsa routines::bad signature::../crypto/rsa/rsa_pss.c:143:ossl_rsa_verify_PKCS1_PSS_mgf1
2025-11-27T08:31:26.281262+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> OpenSSL: error:1C880004:Provider routines::RSA lib::../providers/implementations/signature/rsa_sig.c:1084:rsa_verify_directly
2025-11-27T08:31:26.281311+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> OpenSSL: error:0A00007B:SSL routines::bad signature::../ssl/statem/statem_lib.c:582:tls_process_cert_verify
2025-11-27T08:31:26.281353+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS_ERROR: BIO read tls_read_plaintext error
2025-11-27T08:31:26.281402+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS Error: TLS object -> incoming plaintext read error
2025-11-27T08:31:26.281719+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS Error: TLS handshake failed
2025-11-27T08:31:26.281766+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_free
2025-11-27T08:31:26.281806+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PKCS#11: __pkcs11h_openssl_ex_data_free entered - parent=0x575b0f8c3cc0, ptr=(nil), ad=0x575b0f8c3d50, idx=1, argl=0, argp=0x72efb3a80ac3
2025-11-27T08:31:26.281839+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_free
2025-11-27T08:31:26.281879+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_free
2025-11-27T08:31:26.281922+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS: tls_session_init: entry
2025-11-27T08:31:26.281956+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_init seq_backtrack=64 time_backtrack=15
2025-11-27T08:31:26.281995+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_init seq_backtrack=64 time_backtrack=15
2025-11-27T08:31:26.282023+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS: tls_session_init: new session object, sid=a9758fd7 30b00b25
2025-11-27T08:31:26.282068+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS: tls_multi_process: i=2 state=S_UNDEF, mysid=00000000 00000000, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC]
2025-11-27T08:31:26.282113+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> Fatal TLS error (check_tls_errors_co), restarting
2025-11-27T08:31:26.282153+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> SIGUSR1[soft,tls-error] received, client-instance restarting
2025-11-27T08:31:26.282196+00:00 sgw02 ovpn-server[87519]: MULTI: multi_close_instance called

ovpn is v2.6 and ossl has v3.5.4. We have already tried on both sides to enforce
tls-cert-profile legacy
and tls 1.2.
Forcing ossl to legacy also did not help.

I suspect that the stick simply does not support pss, but we are also unable to get the server to accept the old procedure. The signature algorithm is sha256RSA.
Unfortunately, over 1000 tokens are already in the field and a worldwide replacement is difficult.

Has anyone had any experience with this or have any ideas about what we should check or try?

Kind regards,

Charly
_______________________________________________
Openvpn-users mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/openvpn-users