David explains correctly what happens. This started happening for us on Debian testing with the release of the libengine-pkcs11-openssl package version 0.2.1-2 in March 2016 and it took us a while to analyze the issue. The package had changed the libpkcs11.so location from /usr/lib/ssl/engines/libpkcs11.so to /usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/libpkcs11.so. Since this move the autoload of the pkcs11 engine on the ENGINE_by_id call works and we get a pkcs11 engine initialized for the use of p11-kit instead of the expected initialization for the specified opencryptoki module. We initialize the pkcs11 engine and module path via D-Bus via the SetPKCS11EngineAndModulePath method. David, is the general recommendation to switch over to p11-kit? On Mon, Jun 6, 2016 at 10:26 AM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > On Sun, 2016-06-05 at 17:06 +0300, Jouni Malinen wrote: > > On Mon, May 30, 2016 at 07:19:40PM +0200, Michael Schaller wrote: > > > The first ENGINE_by_id call (line 730) in > > > tls_engine_load_dynamic_generic is used to check if a certain OpenSSL > > > engine is already loaded: > > > https://w1.fi/cgit/hostap/tree/src/crypto/tls_openssl.c#n730 > > > > > > This ENGINE_by_id call has a side effect though that it automatically > > > loads that engine with the default options if the shared object of > > > that engine can be found by openssl. This means that if the autoload > > > succeeds then this check will always be true and hence this engine > > > can't ever be loaded with the specific options for WPA supplicant as > > > specified in the configuration. > > > > Could you please provide some more details on a case where this happens > > and what those specific options in the configuration would be? > > > > I tried to test this myself, but for some reason, did not see OpenSSL > > being able to load any engine automatically.. > > Historically, the PKCS#11 engine required you to jump through a lot of > hoops to load and use it. We fixed this fairly recently. I suspect it's > only Fedora where you can expect it to work out of the box with the > distribution packages so far, but it will reach other distributions in > time. > > You used to have to load the engine manually, and you used to have to > specify the PKCS#11 module manually. > > Now you don't. It's named 'libpkcs11.so' in the OpenSSL engines > directory so it's loaded automatically with ENGINE_by_id(), and it > loads p11-kit-proxy.so as its module by default — so the system- > configured PKCS#11 tokens for the process in question are automatically > available. > > So it really should be as simple as loading the module, then using a > PKCS#11 URI (as specified in RFC7512) to reference the key and/or > certificate. > > In commit 96955192 I already fixed the code to automatically load the > PKCS#11 engine when the string given for the cert or key starts with > 'pkcs11:' and thus looks like a standard PKCS#11 URI. > > > Anyway, looking at the > > related configuration parameters, other than the specific directory of > > the engine file, the only thing that seems to impact the engine loading > > operations seems to be the module patch for pkcs11. And even that could > > potentially be set with ENGINE_ctrl_cmd_string() after the > > ENGINE_by_id() call.. > > All of that is legacy crap. You shouldn't need it these days. > > > I'm not very familiar with the existing OpenSSL engine cases, so it is > > somewhat difficult to speculate on the best way of addressing this, > > though. > > The most interesting use case is when you just put a PKCS#11 URI into > the 'private_key' or 'client_cert' fields instead of a file name, and > it Just Works™. > > Import a cert into gnome-keyring or something like that (using > seahorse). Run 'p11tool --list-all pkcs11:token=Gnome2%20Key%20Storage' > and note the URL of the key and/or cert you want to use. Put them into > the configuration file. That's it¹. > > You can also use certs/keys from your NSS softoken database, if you ask > nicely. > > There are other engines, which are mostly uninteresting because people > should be offering PKCS#11 modules for their hardware instead of > OpenSSL-specific engines. And there are historical and/or badly- > configured or badly-installed instances of ENGINE_pkcs11. Which aren't > worth pandering to if they've been broken since 2002 either, > > (Although if they've only been broken since last year when I changed a > bunch of stuff here, then fixing them *might* make sense). > > -- > David Woodhouse Open Source Technology Centre > David.Woodhouse@xxxxxxxxx Intel Corporation > > > ¹ By using gnome-keyring as the example, I've neatly side-stepped the > question of providing the PIN, which is unfortunately still *different* > in the wpa_supplicant config file depending on whether you're using > GnuTLS or OpenSSL, IIRC. That ought to be uniform, but isn't. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
