Issue with current PKCS#11 support

Dmitrii Pichulin pdn at
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:
> Hi,
> 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 ?
> Cheers,
> Thomas Calderon

More information about the nginx-devel mailing list