Error processing authn response. Lasso error: [-111] Failed to verify signature.,

[schau87]

Any known issue with RHEL/Rocky 9.1 ? It works fine on RHEL/Rocky 8.7/Ubuntu 22.04.
I am trying to setup set Up SSO in Apache using Mellon and Azure AD on RHEL9.1.
With mod_auth_mellon module v0.18.0 , I see the following error message just after the response for the request "POST - /mellon/postResponse":

[APLOG_ERR auth_mellon_handler.c:2201] Error processing authn response. Lasso error: [-111] Failed to verify signature., SAML Response: StatusCode1="urn:oasis:names:tc:SAML:2.0:status:Success", StatusCode2="(null)", StatusMessage="(null)"

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.1_release_notes/known-issues : Here, I see some known issues with SHA signatures but not very sure if this is related to the above error message.

[thijskh]

Are the responses signed using SHA-1 or not?

[schau87]

Thanks for your quick response.
On the Azure ADside, I am using the defaults

Do I need to change it to SHA-1 ? If yes, I already tried changing it and the error message remains the same.

[thijskh]

No, it should be SHA-256. As I do not have handson experience with Rocky 9 yet I do not know what the issue is. Does it help to enable Mellon Diagnostics to get more information?

[schau87]

I already have this enabled on my Apache configuration "MellonDiagnosticsEnable On" but cannot understand everything apart some 400 Response codes in the log messages. On the browser, I see this:

Bad Request

Your browser sent a request that this server could not understand.

[thijskh]

Maybe @simo5 @jhrozek have some more hands on experience with running mod_mellon on RH 9.

[simo5]

@thijskh on RHEL-9 we disable SHA-1 based signatures.
It can be re-enabled by setting a custom policy or by setting the LEGACY policy (but the latter also enables a bunch of other broken algorithms system-wide you do not want to have enabled generally).

SHA-1, especially in certificates, is considered broken these days, my advice is to upgrade your infrastructure to use SHA-256 or better and remove any uses of SHA-1 for signatures if possible.

[simo5]

Note that the whole certificate chain matters. If any intermediary CA is signed with SHA-1, RHEL will refuse to validate the certs.

[thijskh]

Note that it has not been definitively established that the OP actually uses SHA-1 somewhere.

[simo5]

What signing algorithm is actually being used?
SHA-256 is just a digest mechanism. Is this using small (< 2048bit) RSA keys? Smal ECC (< P-256) keys? Or something else entirely?

[schau87]

I am using SHA-256 for the SSL certificates + SAML. Here is some information from the diagnostics + the openssl command:
MellonSignatureMethod (signature_method): rsa-sha256

I looked at the mellon.cert file under ~/etc/apache/mellon and RSA Public-Key - (3072 bit) . Do you mean MellonSPPrivateKeyFile ? I am not sure how to decrypt it.

[schau87]

Additionally, the mellon_create_metdata uses the following:

cat >"$TEMPLATEFILE" <<EOF
RANDFILE           = /dev/urandom
[req]
default_bits       = 3072
default_keyfile    = privkey.pem
distinguished_name = req_distinguished_name
prompt             = no
policy             = policy_anything
[req_distinguished_name]
commonName         = $HOST
EOF

openssl req -utf8 -batch -config "$TEMPLATEFILE" -new -x509 -days 3652 -nodes -out "$OUTFILE.cert" -keyout "$OUTFILE.key" 2>/dev/null

[simo5]

If you change the crypto policy on the system to LEGACY, and restart the services, does it start working?

You can test that with:
# update-crypto-policies --set LEGACY

Remmebr to set it back to DEFAULT policy after the test and restart the services.

[djrodgerspryor]

We're seeing this same error on RockyLinux 9 (Apache/2.4.53 (Rocky Linux) OpenSSL/3.0.1) even after running update-crypto-policies --set DEFAULT:SHA1, and even when the SAML responses being processed (from a Google Workspace IdP) only use SHA256 (for both digest and signature).

The lasso logs do mention sha1, so I wonder if there's some lasso+openssl3.0 incompatibility to do with the removal of SHA1 as a default algo (even if it has been re-enabled):

(process:18): Lasso-CRITICAL **: 12:58:10.133: 2023-01-24 12:58:10 (tools.c/:1562) Error: failed to limit allowed sha1 signature transforms
[Tue Jan 24 12:58:10.133290 2023] [auth_mellon:error] [pid 18:tid 18] [client 10.20.19.229:61701] Error processing authn response. Lasso error: [-111] Failed to verify signature., SAML Response: StatusCode1="urn:oasis:names:tc:SAML:2.0:status:Success", StatusCode2="(null)", StatusMessage="(null)", referer: https://accounts.google.com/

(process:85): Lasso-CRITICAL **: 12:58:19.964: 2023-01-24 12:58:19 (tools.c/:1562) Error: failed to limit allowed sha1 signature transforms
[Tue Jan 24 12:58:19.964608 2023] [auth_mellon:error] [pid 85:tid 85] [client 10.20.19.229:61846] Error processing authn response. Lasso error: [-111] Failed to verify signature., SAML Response: StatusCode1="urn:oasis:names:tc:SAML:2.0:status:Success", StatusCode2="(null)", StatusMessage="(null)", referer: https://accounts.google.com/

[simo5]

This is the piece of code in lasso that is throwing the error:

	if (lasso_get_min_signature_method() <= LASSO_SIGNATURE_METHOD_RSA_SHA1) {
		if ((xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformSha1Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformHmacSha1Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformDsaSha1Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformRsaSha1Id) < 0)) {

			message(G_LOG_LEVEL_CRITICAL, "Error: failed to limit allowed sha1 signature transforms");
			return FALSE;
		}

		if (xmlSecDSigCtxEnableReferenceTransform(dsigCtx, xmlSecTransformSha1Id) < 0) {

			message(G_LOG_LEVEL_CRITICAL, "Error: failed to limit allowed sha1 reference transforms");
			return FALSE;
		}
	}

So yeah, it seam lasso added its own sha1 blockage on top of what OpenSSL does in EL9

[simo5]

Or perhaps I fail to understand what this is checking, it seem there are similar checks for SHA256 and up, so I am not sure I understand what is the intent of the code yet.

[simo5]

In EL9 lasso is compiled with --with-min-hash-algo=sha256 so I am not sure sha1 canb actually be re-enabled at all, although this does not really explain why the error, unless there is some certificate/signature in the chain that depends on verifying a sha1 based signature as far as I can tell.

[schau87]

If you change the crypto policy on the system to LEGACY, and restart the services, does it start working?

You can test that with: # update-crypto-policies --set LEGACY

Remmebr to set it back to DEFAULT policy after the test and restart the services.

Thanks for your feedback. I tried this but no luck. The error message remains the same.

[automate-this]

I have the same problem. Could it be because the DigiCert Root CA certificate that is used for the Azure Federation Endpoint is signed with SHA-1?

[simo5]

If this is a subordinate CA yes.
If it is a parent CA it should just be implicitly trusted and should not cause issues, but it is possible lasso/nod_auth_mellon is still checking it explicitly for some reason and failing.
That would be a bug in whatever component is forcing to check the signature of a certificate marked as implicitly trusted.

[techtug-a]

We have the same issue on AlmaLinux 9.1:

(process:135946): Lasso-CRITICAL **: 15:51:30.978: 2023-01-30 15:51:30 (tools.c/:1512) Error: failed to limit allowed signature transforms
[Mon Jan 30 15:51:30.978149 2023] [auth_mellon:error] [pid 135946:tid 135946] [client 127.0.0.1:44726] Error processing authn response. Lasso error: [-111] Failed to verify signature., SAML Response: StatusCode1="urn:oasis:names:tc:SAML:2.0:status:Success", StatusCode2="(null)", StatusMessage="(null)", referer: https://login.microsoftonline.com/

# update-crypto-policies --set LEGACY did not help.

[Honko003]

Same behaviour is seen on Rocky 9.1 with both the avaiable Lasso package from repo (lasso-2.7.0-8.el9.x86_64) and a Lasso 2.8.0 -package ( taken from https://lemonldap-ng.org/redhat/extras/9/x86_64/lasso-2.8.0-1.el9.x86_64.rpm )

My env :

• NetIQ AccessManager IDP v5.0.3
• Wildcard Sectigo certificate with Signature algorythm SHA 256
• SP with mod_auth_mellon-0.17.0-7.el9.x86_64

[anthonysomerset]

confirming same behaviour on Ubuntu 22.04 it seems to be running the same versions of lasso as Rocky/Alma 9 ultimately

[ipm-uma]

Has anyone managed to make it work?

I have the same error in Rocky Linux 9.1:
lasso-2.7.0-8.el9.x86_64
mod_auth_mellon-0.17.0-7.el9.x86_64

[techtug-a]

@ipm-uma

look into this post, there you can find suggestions/alternatives.
https://forum.checkmk.com/t/saml-2-0-failed-to-verify-signature/36630/43

br,
fred

[saste]

In my case, this was fixed by changing the Canonicalization and Transform methods to xml-exc-c14N without comments at the IdP level (in place of #WithComments variants), might be due to a parsing issue on lasso.

[ipm-uma]

It still happens in Rocky Linux 9.4 with:
lasso-2.7.0-11.el9.x86_64
mod_auth_mellon-0.17.0-7.el9.x86_64