"Did you identify why the fork was causing an issue? We should probably try to understand this before, it could be something stupid in haproxy's code or in the pkcs11 provider."
- PKCS#11 drivers contain session objects and handles to private keys in the HSM; these session objects and handles don't always behave well after fork - this is a known problem of a lot of existing PKCS#11 drivers Indeed GnuTLS says: "Note that, PKCS #11 modules behave in a peculiar way after a fork; they require a reinitialization of all the used PKCS #11 resources. While GnuTLS automates that process, there are corner cases where it is not possible to handle it correctly in an automated way. For that, it is recommended not to mix fork() and PKCS #11 module usage. It is recommended to initialize and use any PKCS #11 resources in a single process" This is not a problem of HAProxy specifically - having said this new PKCS#11 v3 drivers may support "fork tolerant semantics": such drivers don't need this kind of RFC which is targeted to drivers without this feature. https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/cs01/pkcs11-base-v3.0-cs01.html - the double caching(ssl_ckch.c/ssl_sock.c) is inelegant and messy just to be able to recall the PEM bytes. I think I have found a way to do it without cache. -- cache PEM data by extending (struct ckch_data*) -- store the (struct ckch_data*) in the SSL_CTX* using SSL_CTX_set_app_data -- let me think about this and come up with another RFC. Cheers Richard
