[gnutls-devel] GnuTLS | PKCS#11 Auto-Initialization Not Working (#1798)

[Read-only notification of GnuTLS library development activities]

Claudio Ferreira commented: https://gitlab.com/gnutls/gnutls/-/issues/1798#note_3089295584


Thank you for your patience and for the detailed investigation!

After extensive testing with your suggested test case, I have important findings to report.

## Summary

Auto-initialization **does work** (modules are loaded), but there's a **timing/state issue** that prevents certificate discovery when initialization happens automatically vs. explicitly.

## Test Results

### Environment
- **GnuTLS**: 3.8.12-2 (with MRs !2014 and !2049 applied)
- **OpenConnect**: 9.12-3.3 (Debian package)
- **Token**: G&D StarSign CUT S (SafeSign IC driver)
- **Certificate**: ICP-Brasil A3

### Test 1: OpenConnect WITHOUT explicit init (stock Debian package)

```bash
GNUTLS_DEBUG_LEVEL=10 /usr/sbin/openconnect --protocol=gp \
  -c "pkcs11:id=%XX%XX%XX%XX" [VPN_SERVER]
```

**Result:**
```
gnutls[2]: p11: Initializing module: safesign
gnutls[2]: p11: Module safesign is initialized in a thread-safe mode
...
gnutls[3]: ASSERT: ../../../lib/auth/cert.c[find_x509_client_cert]:229
...
Valid client certificate is required
```

✅ PKCS#11 auto-initialization **works** (SafeSign loaded)  
❌ Certificate discovery **fails** (`find_x509_client_cert` assertion)  
❌ Empty certificate sent to server (7 bytes)  
❌ Authentication fails

### Test 2: OpenConnect WITH explicit init (patched version)

Same command, but OpenConnect calls `gnutls_pkcs11_init()` explicitly in `openconnect_init_ssl()`:

**Result:**
```
PIN necessário para [TOKEN_NAME]
Insira o PIN:
Usando certificado "[USER_NAME]:[CPF_MASKED]" do cliente
Próxima AC "AC SOLUTI Multipla v5 G2" obtida de PKCS#11
...
Conectado ao HTTP no [VPN_SERVER]
```

✅ PKCS#11 initialized explicitly  
✅ PIN prompt appears  
✅ Certificate **found and loaded** successfully  
✅ Full certificate chain retrieved from token  
✅ VPN connection succeeds

## Analysis

The MRs !2014 and !2049 successfully fixed the **initialization** problem, but there's a subtle **timing/state issue**:

1. **Auto-init (late)**: When GnuTLS initializes PKCS#11 automatically during the first PKCS#11 operation, something in the internal state causes `find_x509_client_cert()` to fail

2. **Explicit init (early)**: When OpenConnect initializes PKCS#11 explicitly in `openconnect_init_ssl()` before any certificate operations, everything works correctly

## Possible Causes

1. **State initialization order**: Auto-init may not fully initialize some internal state needed for certificate discovery
2. **Module registration timing**: Modules registered during auto-init may not be properly available for subsequent operations
3. **p11-kit interaction**: The interaction between GnuTLS and p11-kit may have different behavior depending on initialization timing

## Conclusion

This is **not a false report**, but the problem is more subtle than initially described:

- ✅ Auto-initialization works (modules load)
- ❌ But certificate discovery fails with auto-init
- ✅ Explicit initialization works perfectly

**Question**: Is this expected behavior, or should auto-init guarantee the same state as explicit init?

## Logs Available

I can provide complete debug logs (GNUTLS_DEBUG_LEVEL=10) for both scenarios if helpful.

---

Thank you for your time investigating this. The MRs !2014 and !2049 definitely improved the situation, but there seems to be a remaining issue with certificate discovery timing.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1798#note_3089295584
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20260217/09d273b5/attachment-0001.html>