openssl ca commad with yubikey tokens fails

[gilweis]

Describe the bug
openssl ca commad with yubikey tokens fails.

To Reproduce
Steps to reproduce the behavior:
mkdir demoCA
mkdir demoCA/newcerts demoCA/private
echo "01" > ./demoCA/serial
touch ./demoCA/index.txt

#Creating CA cert:
openssl req -x509 -new -nodes -key "pkcs11:type=private;id=%02" -days 1024 -out ./demoCA/cacert.pem -sha256

#Creating certificate from csr:
openssl ca -out newcert.pem -days 3650 -in tmp.csr -keyfile "pkcs11:type=private;id=%02" -md sha256

error:
CA certificate and CA private key do not match
4087EFF7627F0000:error:05800075:x509 certificate routines:X509_check_private_key:unknown key type:../crypto/x509/x509_cmp.c:411:

Expected behavior
newcert.pem file

Operating environment (please complete the following information):

• OS: Ubuntu
• Version 20.10

Token and application used (please complete the following information):

Device: Yubikey5
PKCS11 Driver version: [e.g. 1.3.4]
Application openssl
Version 3.0.5

Additional context

[simo5]

So I traced this down to OpenSSL trying to export the private key in the routine that checks if the private key is the key corresponding to the CA cert.
This is unconditional in 3.0.5 code and also in master until recently when this commit was pushed:
openssl/openssl@c2f8d71
(I can't find the PR that pushed it, the one mentioned in the commit comment does not show it).
This commit allows to check if the pkey passed in also "has" a public key, and then proceed to put OSSL_KEYMGMT_SELECT_PUBLIC_KEY in the selection which would allow to ask to export only a public key and that would work.

Except that we would not return positively to:
evp_keymgmt_util_has((EVP_PKEY *)b, OSSL_KEYMGMT_SELECT_PUBLIC_KEY)
if we have a private key currently.

However the work I recently pushed that allows us to try to find the associated public key when we have a private key means we can now always try to respond that yes we do have a public key, even if the type is a private key, and then hope it works.

This commit landed in 3.0.6 though so it won't work until distributions pick it up.
I can try to see if I can fix this to work with openssl's master tree in the meanwhile ...

[simo5]

Ah upon further analysis the OpenSSL code won't work even with the code in master, because although in master EVP_PKEY_eq() will pass the right selection to evp_pkey_cmp_any(), this function does not use it when trying to export keys.

The key export is done in evp_keymgmt_util_match() to which selection is passed but it calls evp_keymgmt_util_export_to_provider() which does not take a slection argument and instead itself calls evp_keymgmt_util_export() with OSSL_KEYMGMT_SELECT_ALL unconditionally.

@t8m does this qualify as an openssl bug?

Looking at evp_keymgmt_util_match() the intention seem to always use selection to later match the keys, so it seem to me that calling evp_keymgmt_util_export_to_provider() which does not take a selection is an issue borne from the fact there isn't a util function that takes a selection argument to export to a provider. Perhaps it is just a matter of adding a slection argument to this function?

[simo5]

Wrong mention, @t8m ^

[t8m]

Yeah, I'd call this a bug. There might be some reservations about backporting it to 3.0.x but IMO it should definitely be fixed in master and 3.1 branches.

[t8m]

There is one peculiarity though - fixing this is not that simple as it seems from the first sight because the evp_keymgmt_util_export_to_provider() creates a cached exported entry inside the EVP_PKEY and that cache does not distinguish the selection - it would have to be changed to recognize different selections so the next time the EVP_PKEY is used with some private key operation it attempts full export to the provider and won't try to reuse the cached public key only export.

[simo5]

@t8m ok I think we should move further discussion to an openssl bug, I will try to give it some meat