+++ This bug was initially created as a clone of Bug #2063838 +++
The signature verification part of the krb5 PKINIT plugin was initially implemented using PKCS7_verify, and error handling was written according to this function.
This code was modified to use CMS_verify when building against >= OpenSSL 1.0, but kept PKCS7_verify error codes handling.
As a consequence, the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error, which should explain the digest algorithm is not support is no raised and an unrelated error is displayed:
"Failed to verify CMS message: content type not enveloped data"
Actual CMS_verify error codes should be handled.
--- Additional comment from Julien Rische on 2022-07-29 15:51:59 UTC ---
There are 2 points to fix:
* Error codes have to be modified to match the new function.
* The last error from OpenSSL stack should be picked rather that the first one which is always CMS_R_CONTENT_TYPE_NOT_ENVELOPED_DATA, therefore it does not allow to differentiate an error caused by an unaccepted digest algorithm and an invalid signature.
The error code we could expect based on the code of OpenSSL CMS signature verification are:
* CMS_R_NO_MATCHING_SIGNATURE (not used in practice)
But I've run some tests and the error codes that seems to be actually raised are:
* EVP_R_INVALID_DIGEST: the OID is recognized the algorithm is not allowed by the policy in signature verification
* RSA_R_DIGEST_NOT_ALLOWED: OpenSSL fails to infer a signature algorithm based on the digest one and the key type (the more generic code PROV_R_DIGEST_NOT_ALLOWED might be considered too)
* CMS_R_VERIFICATION_FAILURE: signature verification failed
We should use ERR_peek_last_error() instead of ERR_peek_error() in order to get these error codes.
--- Additional comment from Julien Rische on 2022-08-02 07:40:20 UTC ---
--- Additional comment from Julien Rische on 2022-08-19 08:47:10 UTC ---
EVP_R_INVALID_DIGEST is actually raised by code in a downstream OpenSSL patch. I will handle it in a krb5 downstream patch too.
FEDORA-2022-8050ab2c35 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8050ab2c35
FEDORA-2022-311128dd7e has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-311128dd7e
FEDORA-2022-311128dd7e has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.