Hi Carsten,
On 27/11/2025 14:05, Carsten Mietzsch wrote:
Unfortunately, I forgot to mention that it worked under Debian 11 with
ovpn 2.4 and ossl 1.1.1w, and it was the update to Deb 13 that caused
the problem.
the certificate looks OK though I cannot fully verify it without the
sub-CA and CA you use.
Are you loading the certificate from the token itself? I would try
debugging this by extracting the certificate and using the token only
for the private key.
Also, you could try using the pkcs11_engine (or pkcs11_provider) to try
to access it using the `openssl` command line tool.
HTH,
JJK
*Von:*Jan Just Keijser <[email protected]>
*Gesendet:* Donnerstag, 27. November 2025 13:19
*An:* Carsten Mietzsch <[email protected]>;
[email protected]
*Cc:* Wilhelm Greiner <[email protected]>
*Betreff:* Re: [Openvpn-users] Problem with Athena signed rsa pkcs
Hi Charly,
I've dealt with similar stuff in the past - is it possible for you to
extract a certificate from the token and share that here? that will
give some insight into the problem.
Regards,
JJK
On 27/11/2025 11:34, Carsten Mietzsch via Openvpn-users 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 Sent fatal SSL alert: decrypt error
2025-11-27T08:31:26.281207+00:00 sgw02 ovpn-server[87519]:
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 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 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 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 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 TLS Error: TLS handshake failed
2025-11-27T08:31:26.281766+00:00 sgw02 ovpn-server[87519]:
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 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 PID packet_id_free
2025-11-27T08:31:26.281879+00:00 sgw02 ovpn-server[87519]:
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 TLS: tls_session_init: entry
2025-11-27T08:31:26.281956+00:00 sgw02 ovpn-server[87519]:
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 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 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 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 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 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users
_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users
