Hi Alex,
On 29/10/2021 14:32, Alex Dankow wrote:
Hi OpenSSL team!
I wrote a provider for Windows certificates and implemented "openssl ca".
Now, I think it would be fun to see a HTTPS server using certificates
installed in Windows storage.
Nice!
Certificate is loaded using load_cert_pass (taken from apps.c) with
custom uri "wincert://11:22:33....", private key is loaded with
load_key from apps.c too. It works, but ...
When I use SSL_CTX_use_PrivateKey(ctx, myprivk) the key is declined.
OpenSSL compares strings and expects "rsaEncryption", and so on instead
of "MYKEY". Why ?
It's not entirely clear to me what you are attempting here. Are your
certificates/keys stored in Windows storage standard RSA/ECDSA etc
certs? Or are they using some custom algorithm?
If they are standard RSA/ECSDA certs then you should be using the
correct standard algorithm names in you keymgmt etc and it should all
"just work".
Unfortunately, in 3.0, libssl only supports standard algorithms. We have
discussed a "pluggable" signature scheme mechanism which would enable
plugging in arbitrary algorithms but it didn't make it for 3.0:
https://github.com/openssl/openssl/issues/10512
I'd still like to get back to that at some point but we don't have it
yet. It should be entirely possible with the new provider architecture -
and in fact we *did* add pluggable kex/kem support for libssl. But we
just ran out of time with pluggable signatures.
https://github.com/openssl/openssl/pull/11914
https://github.com/openssl/openssl/pull/13018
Matt
Maybe I'm missing something, but if you built a key management system,
sign interface, ciphers that allows key virtualization, why not go
further ? I'm ready to implement the encryption interface, but why
OpenSSL still care about key type name. In the new era of version 3, it
can check if the key provides necessary interfaces.
--
Alex Dankow
