Re: Problem with Athena signed rsa pkcs
Jan Just Keijser <[email protected]> Thu, 27 Nov 2025 17:10:46 +0100
| Newsgroups | gmane.network.openvpn.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============9024874886091125162== Content-Type: multipart/alternative; boundary="------------eu7E2O14wEGkTbDbTgeCuaAY" Content-Language: en-US This is a multi-part message in MIME format. --------------eu7E2O14wEGkTbDbTgeCuaAY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > --------------eu7E2O14wEGkTbDbTgeCuaAY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">Hi Carsten,<br> <br> On 27/11/2025 14:05, Carsten Mietzsch wrote:<br> </div> <blockquote type="cite" cite="mid:BESPR09MB83108764EDFEE883816130FCF9DFA@BESPR09MB8310.eurprd09.prod.outlook.com"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style>@font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face {font-family:Aptos;}@font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:11.0pt; font-family:"Calibri",sans-serif; mso-ligatures:standardcontextual; mso-fareast-language:EN-US;}a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}pre {mso-style-priority:99; mso-style-link:"HTML Vorformatiert Zchn"; margin:0cm; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";}span.HTMLVorformatiertZchn {mso-style-name:"HTML Vorformatiert Zchn"; mso-style-priority:99; mso-style-link:"HTML Vorformatiert"; font-family:Consolas; mso-ligatures:standardcontextual; mso-fareast-language:EN-US;}span.E-MailFormatvorlage22 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif; color:windowtext;}.MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;}div.WordSection1 {page:WordSection1;}</style> <div class="WordSection1"><br> <p class="MsoNormal"> 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.<o:p></o:p></p> </div> </blockquote> <br> the certificate looks OK though I cannot fully verify it without the sub-CA and CA you use.<br> 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.<br> <br> Also, you could try using the pkcs11_engine (or pkcs11_provider) to try to access it using the `openssl` command line tool.<br> <br> HTH,<br> <br> JJK<br> <br> <blockquote type="cite" cite="mid:BESPR09MB83108764EDFEE883816130FCF9DFA@BESPR09MB8310.eurprd09.prod.outlook.com"> <div class="WordSection1"> <p class="MsoNormal"><o:p> </o:p></p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> <p class="MsoNormal"><b><span style="mso-ligatures:none;mso-fareast-language:DE">Von:</span></b><span style="mso-ligatures:none;mso-fareast-language:DE"> Jan Just Keijser <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> <br> <b>Gesendet:</b> Donnerstag, 27. November 2025 13:19<br> <b>An:</b> Carsten Mietzsch <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>>; <a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><br> <b>Cc:</b> Wilhelm Greiner <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>><br> <b>Betreff:</b> Re: [Openvpn-users] Problem with Athena signed rsa pkcs<o:p></o:p></span></p> </div> </div> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal">Hi Charly,<br> <br> 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.<br> <br> Regards,<br> <br> JJK<br> <br> <br> On 27/11/2025 11:34, Carsten Mietzsch via Openvpn-users wrote:<span style="font-size:12.0pt;mso-ligatures:none;mso-fareast-language:DE"><o:p></o:p></span></p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal">Hi,<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">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:<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">2025-11-27T08:31:26.281152+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 Sent fatal SSL alert: decrypt error<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">2025-11-27T08:31:26.281719+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS Error: TLS handshake failed<o:p></o:p></p> <p class="MsoNormal">2025-11-27T08:31:26.281766+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_free<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">2025-11-27T08:31:26.281839+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_free<o:p></o:p></p> <p class="MsoNormal">2025-11-27T08:31:26.281879+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_free<o:p></o:p></p> <p class="MsoNormal">2025-11-27T08:31:26.281922+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS: tls_session_init: entry<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">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]<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">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<o:p></o:p></p> <p class="MsoNormal">2025-11-27T08:31:26.282196+00:00 sgw02 ovpn-server[87519]: MULTI: multi_close_instance called<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">ovpn is v2.6 and ossl has v3.5.4. We have already tried on both sides to enforce <o:p></o:p></p> <p class="MsoNormal">tls-cert-profile legacy<o:p></o:p></p> <p class="MsoNormal">and tls 1.2.<o:p></o:p></p> <p class="MsoNormal">Forcing ossl to legacy also did not help.<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">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.<o:p></o:p></p> <p class="MsoNormal">Unfortunately, over 1000 tokens are already in the field and a worldwide replacement is difficult.<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">Has anyone had any experience with this or have any ideas about what we should check or try?<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">Kind regards,<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">Charly<o:p></o:p></p> <p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;mso-ligatures:none;mso-fareast-language:DE"><br> <br> <o:p></o:p></span></p> <pre>_______________________________________________<o:p></o:p></pre> <pre>Openvpn-users mailing list<o:p></o:p></pre> <pre><a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><o:p></o:p></pre> <pre><a href="https://lists.sourceforge.net/lists/listinfo/openvpn-users" moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.sourceforge.net/lists/listinfo/openvpn-users</a><o:p></o:p></pre> </blockquote> <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;mso-ligatures:none;mso-fareast-language:DE"><o:p> </o:p></span></p> </div> </blockquote> <br> </body> </html> --------------eu7E2O14wEGkTbDbTgeCuaAY-- --===============9024874886091125162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============9024874886091125162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Openvpn-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-users --===============9024874886091125162==--