On Wed, Dec 13, 2023 at 11:33:16AM +0100, Ingo Franzki wrote: > On 13.12.2023 10:55, Joe Orton wrote: > > On Wed, Dec 06, 2023 at 01:02:01PM +0100, Yann Ylavic wrote: > >> Oh, scratch that. Actually the engine API requires a "SSLCryptoDevice > >> pkcs11" too, so we wouldn't take the !mc->szCryptoDevice path. > >> Sorry for the noise. > > > > Yes it should remain compatible like that, though you prompted me to > > re-read that and it would break for a no-engine build: r1914622. > Good catch! > How would one compile without OpenSSL having the engine API ? > At least currently, any supported OpenSSL version still does have the Engine > API.
If you configure OpenSSL with the "no-engine" flag, you get OPENSSL_NO_ENGINE #define'd in the OpenSSL headers, and the engine API is not available. Looks like a few more places which assume ->szCryptoDevice is always there, so there may be other build issues. We need a CI config for this. > > I am not sure but we might want to add a new directive (yay) which loads > > a named provider, or we could rely on users doing that in openssl.cnf > > since configuring providers may be non-trivial (e.g. [1]). > I would not try to load a named provider. While loading a named provider can > be done using the OpenSSL provider API, > it is not possible to supply configuration parameters to that provider after > loading it. > Most provider I know do need specific configuration settings, they won't work > without them, especially the PKCS#11 providers. > So we must rely on users doing that in openssl.cnf. That makes sense to me, thank you. > > Other thing a colleage mentioned was that we may want to expand the list > > of URI schemes accepted here from just pkcs11://. > Sure, the provider code in general should work for any kind of URIs, not only > 'pkcs11:'. > It would even work for the 'file:' URI, loading the keys/certs from PEM files > (like the non-provider/non-engine code is doing already). > Actually it would even work for file names without a scheme at all, since the > default scheme is 'file:' anyway. > So it could theoretically replace the non-provider/non-engine load key/cert > code (not that I would suggests to change that as of today....). Yup. We would have to be careful to make the logic around loading the chain from the file would work exactly the same if a file:// URI was used. I'm not sure what the best approach is - try loading everything via a store and then fallback to the old way, or again add a new config option(s?) SSLBlahURI. Regards, Joe
