patch to allow loading PKCS #11 URLs
mdounin at mdounin.ru
Mon Jul 6 00:00:50 UTC 2015
On Wed, Jun 24, 2015 at 03:26:17PM +0200, Nikos Mavrogiannopoulos wrote:
> On Mon, 2015-06-22 at 11:06 +0200, Nikos Mavrogiannopoulos wrote:
> > The current support relies on engine_pkcs11, which is a 3rd party
> > module (not in openssl distribution). It should be future-proof to
> > have
> > a way to load PKCS #11 modules which is independent of the backend
> > used
> > by nginx. So you could change the internal backend (for example to
> > use
> > libp11 directly), without requiring all nginx users to change their
> > configuration files and remove the "engine:pkcs11:" part from their
> > keys.
> To add to this, it seems that the current PKCS #11 support in nginx is
> broken. It will only work with softhsm which is a simplistic soft
> module. Hardware HSMs, and more advanced soft HSMs like caml-crush
> require strict PKCS #11 adherence which neither engine_pkcs11 or nginx
> have. That is, they require the reinitialization of any open PKCS #11
> modules and object handles after a fork.
> I think, the simplest way is to solve that within engine_pkcs11 with an
> atfork handler and reinitialization on re-use... but that would be
> quite messy.
> For more info see:
Yes, this was already discussed in the thread here:
This is believed to be a problem in engine_pkcs11, and should be
fixed there. From nginx point of view it just uses keys from an
engine, and it's engine responsibility to handle any details,
including any reinitialization after fork() if needed.
More information about the nginx-devel