I'm not sure what you mean by sscep has an option to "utilize a different certificate for encryption which we leverage." Can you provide more details?

And can you provide some certmonger logging output when the failure occurs?

For sscep, please see the -e enroll option. https://github.com/certnanny/sscep#how-to-use

For logs, please see attached. This is from running in the foreground with -d 5. I've stripped certificate and hostnames (policy). I've split the logs into adding the ca and making the request. From inspecting the pkcs7 blob with openssl pkcs7 -print ... the issuer serial lines up with the RA digital signature certificate however the logs show scep_ra_cert being set to the key encipherment cert but it is included in scep_certificates.

Do you have an error in the vother certs output? Should the first one be "RA Digital Signature" and not "RA Key Encipherment"?

What cert actually signed the PKCS#7 response?

Sorry that is typo on my part while minimizing things, vother[1] is the digital signature...reasons not to do things manually...hah

On the PKCS7 -> signer info -> issuer is the digital signature based on the serial number.

I should have done more testing, it appears sscep also does not work for us on alma 9. With some more debugging and env parameters it has to do with using sha1 signatures still and those being disabled by default in openssl 3. Sorry for the confusion on the initial report(s). For sscep I was able to work around this limitation by setting some env variables and defining a custom conf that still allowed sha1.

I am not sure how to have these apply for/test with certmonger. I did try running in the foreground with the env set but it didn't seem to have any effect. If it is spawning another program (pretty sure it is) I wouldn't expect the env to be carried forward.

[1] https://github.com/openssl/openssl/issues/17662
[2] https://github.com/certnanny/sscep/issues/157

Setting environment variables would require hacking some code. From what I read you should be able to do this with pure openssl configuration though, on a RHEL-based system anyway.

Looking at https://bugzilla.redhat.com/show_bug.cgi?id=2070977 I tried the TLS test script and the signing steps in comment #5 with this change to openssl.cnf and sha-1 worked ok, at least for this use-case.

--- /etc/pki/tls/openssl.cnf    2022-10-26 12:02:22.000000000 -0400
+++ openssl.cnf 2022-11-08 11:35:12.780640013 -0500
@@ -43,6 +43,7 @@
 tsa_policy3 = 1.2.3.4.5.7
 [openssl_init]
+alg_section = evp_properties
 providers = provider_sect
 # Load default TLS policy configuration
 ssl_conf = ssl_module
@@ -55,6 +56,9 @@
 # In general it is not recommended to use the above mentioned algorithms for
 # security critical operations, as they are cryptographically weak or vulnerable
 # to side-channel attacks and as such have been deprecated.
+#
+[evp_properties]
+rh-allow-sha1-signatures = yes
 [provider_sect]
 default = default_sect

A simpler approach might be to try:

# update-crypto-policies --set DEFAULT:SHA1

I can confirm the above policy update get things working for us. Thanks for providing those insights.