Hi, (+Cc: gnutls-help. This is about the failure of ‘guile/tests/reauth.scm’ observed on Debian.)
Thanks Rob & Vagrant. The debugging output Vagrant posted reads: --8<---------------cut here---------------start------------->8--- [10219|3] Peer requested CA: CN=GNUTLS TEST SERVER,OU=GNUTLS,O=FSF,C=GR [10219|3] Peer requested CA: CN=GNUTLS INTERMEDIATE TEST CA,OU=GNUTLS,O=FSF,C=GR [10219|4] checking cert compat with RSA-SHA256 [10219|3] ASSERT: ../../../lib/ext/signature.c[_gnutls_session_sign_algo_enabled]:433 [10219|4] Signature algorithm RSA-SHA256 is not enabled [10219|4] checking cert compat with RSA-PSS-SHA256 [10219|4] throw to `gnutls-error' with args (#<gnutls-error-enum Public key signing has failed.> read_from_session_record_port) checking cert compat with RSA-PSS-RSAE-SHA256 [10219|4] HSK[0x55c505382030]: CERTIFICATE was queued [693 bytes] [10219|5] REC[0x55c505382030]: Preparing Packet Handshake(22) with length: 693 and min pad: 0 [10219|5] REC[0x55c505382030]: Sent Packet[8906] Handshake(22) in epoch 2 and length: 715 [10219|4] HSK[0x55c505382030]: signing TLS 1.3 handshake data: using RSA-PSS-RSAE-SHA256 and PRF: SHA384 [10219|3] ASSERT: ../../../lib/nettle/pk.c[_rsa_pss_sign_digest_tr]:805 [10219|3] ASSERT: ../../../lib/nettle/pk.c[_wrap_nettle_pk_sign]:1177 [10219|3] ASSERT: ../../../lib/nettle/pk.c[_wrap_nettle_pk_sign]:1190 [10219|3] ASSERT: ../../lib/privkey.c[privkey_sign_and_hash_data]:1300 [10219|3] ASSERT: ../../lib/tls13-sig.c[_gnutls13_handshake_sign_data]:205 [10219|3] ASSERT: ../../lib/tls13/certificate_verify.c[_gnutls13_send_certificate_verify]:210 [10219|3] ASSERT: ../../lib/tls13/post_handshake.c[_gnutls13_reauth_client]:117 [10219|3] ASSERT: ../../lib/handshake-tls13.c[_gnutls13_recv_async_handshake]:661 [10219|3] ASSERT: ../../lib/record.c[record_add_to_buffers]:1016 [10219|3] ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1578 [10219|3] ASSERT: ../../lib/record.c[_gnutls_recv_int]:1776 --8<---------------cut here---------------end--------------->8--- When uncommenting the debugging output statements in ‘tests/reauth.scm’ (and only then!), I can reproduce the bug, though it is not systematically in the same spot. In all cases, it’s the client failing to reauthenticate. One example is ‘_nettle_rsa_sec_compute_root_tr’ returning 0 and thus leading to GNUTLS_E_PK_SIGN_FAILED as we see above. The client’s stack at that point looks like this: --8<---------------cut here---------------start------------->8--- (rr) bt #0 _nettle_rsa_sec_compute_root_tr (pub=pub@entry=0x7ffe9499aed0, key=key@entry=0x7ffe9499af00, random_ctx=random_ctx@entry=0x0, random=random@entry=0x7f4535ff91e0 <rnd_nonce_func>, x=x@entry=0x7f4534ff4e00, m=0x7f4534ff4e80, mn=16) at rsa-sign-tr.c:319 #1 0x00007f4535e37a74 in nettle_rsa_compute_root_tr (pub=pub@entry=0x7ffe9499aed0, key=key@entry=0x7ffe9499af00, random_ctx=random_ctx@entry=0x0, random=random@entry=0x7f4535ff91e0 <rnd_nonce_func>, x=x@entry=0x7ffe9499aec0, m=m@entry=0x7ffe9499ae30) at rsa-sign-tr.c:365 #2 0x00007f4535e38de0 in nettle_rsa_pss_sha256_sign_digest_tr (pub=0x7ffe9499aed0, key=0x7ffe9499af00, random_ctx=0x0, random=0x7f4535ff91e0 <rnd_nonce_func>, salt_length=<optimized out>, salt=0xb98230 "\221\251\260\307\351\300\226\326,o\343\303\001\213\340YT\027\023\227\327\004\065\247\374Kje\177C\024_ending eQ", digest=0xb32e70 "\233\255U\366\235I\001\372}\356\261r\257\213b\316\376\fkh\253X", s=0x7ffe9499aec0) at rsa-pss-sha256-sign-tr.c:59 #3 0x00007f4535ffb709 in _rsa_pss_sign_digest_tr (rnd_ctx=0x0, rnd_func=0x7f4535ff91e0 <rnd_nonce_func>, s=0x7ffe9499aec0, digest=<optimized out>, salt_size=<optimized out>, priv=0x7ffe9499af00, pub=0x7ffe9499aed0, dig=<optimized out>) at pk.c:807 #4 _wrap_nettle_pk_sign (algo=<optimized out>, signature=0x7ffe9499b170, vdata=<optimized out>, pk_params=<optimized out>, sign_params=<optimized out>) at pk.c:1175 #5 0x00007f4535f4b374 in privkey_sign_and_hash_data (signer=0xb823a0, se=0x7f4536093a20 <sign_algorithms+224>, data=<optimized out>, signature=0x7ffe9499b170, params=0x7ffe9499b020) at privkey.c:1296 #6 0x00007f4535f4b658 in gnutls_privkey_sign_data2 (signer=signer@entry=0xb823a0, algo=<optimized out>, flags=flags@entry=0, data=data@entry=0x7ffe9499b090, signature=signature@entry=0x7ffe9499b170) at privkey.c:1194 #7 0x00007f4535f61203 in _gnutls13_handshake_sign_data (session=session@entry=0xb893d0, cert=<optimized out>, pkey=0xb823a0, context=0x7f4536089200 <cli_ctx>, signature=signature@entry=0x7ffe9499b170, se=se@entry=0x7f4536093a20 <sign_algorithms+224>) at tls13-sig.c:207 #8 0x00007f4535f608db in _gnutls13_send_certificate_verify (session=session@entry=0xb893d0, again=<optimized out>) at tls13/certificate_verify.c:206 #9 0x00007f4535f65305 in _gnutls13_reauth_client (session=0xb893d0) at tls13/post_handshake.c:115 #10 gnutls_reauth (session=session@entry=0xb893d0, flags=flags@entry=0) at tls13/post_handshake.c:251 #11 0x00007f4535f17a9d in _gnutls13_recv_async_handshake (session=session@entry=0xb893d0) at handshake-tls13.c:657 #12 0x00007f4535f117e2 in record_add_to_buffers (recv=0x7ffe9499b320, bufel=0xb84620, seq=0, htype=4294967295, type=GNUTLS_APPLICATION_DATA, session=0xb893d0) at record.c:1013 #13 _gnutls_recv_in_buffers (session=session@entry=0xb893d0, type=type@entry=GNUTLS_APPLICATION_DATA, htype=htype@entry=4294967295, ms=<optimized out>, ms@entry=0) at record.c:1570 #14 0x00007f4535f12221 in _gnutls_recv_int (session=0xb893d0, type=GNUTLS_APPLICATION_DATA, data=0x7f4535c06290 ".rtl-text", data_size=1, seq=0x0, ms=0) at record.c:1773 #15 0x00007f45360a61d6 in read_from_session_record_port (port=<optimized out>, dst=<optimized out>, start=<optimized out>, count=1) at core.c:1051 #16 0x00007f4539f1d280 in scm_i_read_bytes () from /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/lib/libguile-3.0.so.1 --8<---------------cut here---------------end--------------->8--- It looks as though the public or private key were corrupt, but nothing obvious. Unfortunately, there doesn’t seem to be a similar test case in C. The closest one is ‘tls12-rehandshake-cert-auto’, but it uses anonymous certificates and different priority strings. Ideas for further debugging would be welcome! Ludo’.