Issue with current PKCS#11 support
pdn at cryptopro.ru
Fri Apr 10 10:30:08 UTC 2015
This is a common behavior for security providers that do not have own
service running, which can handle objects globally.
nginx loads private keys once then forks then impersonates to user in
config (if set).
In your case, it seems that your PKCS#11 library does not support a fork
or a user change.
You can try to run nginx and its worker processes by the same user
Or you can try to find a better PKCS#11 provider.
On 10.04.2015 13:00, Thomas Calderon wrote:
> I just tried nginx PKCS#11 support that was introduced in 1.7.9.
> In a Debug/Test environment I have a working setup. Namely, using
> "daemon off" and the instructions provided on the mailing list, I manage
> to establish a TLS connection using my token.
> However, when using "daemon on", a client connection spawn the
> worker_process, the PKCS#11 library gets reloaded. However, the PKCS#11
> context is lost, hence the TLS connection cannot be established (further
> function fails since the library is not initilized, objects handles are
> not valid anymore, etc).
> Given the stack used to leverage PKCS#11 support
> (OpenSSL->engine_pkcs11->...), I am not sure how to fix this.
> Did you observe the same behavior ?
> Thomas Calderon
More information about the nginx-devel