Re: GnuTLS | PKCS#11 Auto-Initialization Not Working (#1798)

Read-only notification of GnuTLS library development activities <[email protected]>
Newsgroups gmane.comp.encryption.gpg.gnutls.devel
Message-ID <[email protected]>


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.

_______________________________________________
Gnutls-devel mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.