SAML 2.0 - Failed to verify signature

techtuga · January 30, 2023, 3:32pm

CMK version: Checkmk Raw Edition 2.1.0p18
OS version: ALMA LINUX 9.1

Error message: Failed to verify signature.

Hi,

Unfortunately there seems to be an issue with AlmaLinux 9.1 crypto libs and Lasso. We get the following error when setting up SAML2.0:

(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/

I found this article related to the same issue we have on the Server: Error processing authn response. Lasso error: [-111] Failed to verify signature., · Issue #115 · latchset/mod_auth_mellon · GitHub

Seems this is a bug related to Lasso. Not sure how to get support on this.

Br,
Fred

Glowsome · January 31, 2023, 12:19am

Hello,

A few Questions :

Any versions on the packages you have in use ?
on RHEL8/CentOS8 i had issues with the Lasso Package ( see https://forum.checkmk.com/t/is-checkmk-saml-2-0-capable/23195/6

Glowsome

techtuga · January 31, 2023, 10:41am

Hello Glowsome,

Thanks for your reply.
Do you know how i can check which lasso version mod_auth_mellon.so and checkMK is using?
The only reference i see is

LoadModule auth_mellon_module /omd/sites/${SITE}/lib/apache/modules/mod_auth_mellon.so

Thanks,
Fred

Glowsome · January 31, 2023, 11:15am

Lasso is a separate package, installed as a dependancy so a simple query would be to just ask your packagemanager which version is installed

rpm -qa | grep lasso

Should give you back what version of Lasso your system is using.

i just peeked quickly to see ( on a RockyLinux 9.1 box)

rpm -qa | grep lasso
lasso-2.7.0-8.el9.x86_64

Glowsome

techtuga · January 31, 2023, 12:07pm

I just installed xmlsec1-openssl.
Thhink the mellon module and lasso comes pre-packaged with check_mk, thats why i am asking how to know which version is it using:
/omd/sites/{site}/lib/apache/modules/mod_auth_mellon.so

rpm -qa | grep xmlsec1-openssl
xmlsec1-openssl-1.2.29-9.el9.x86_64

rpm -qa | grep lasso
returns empty

Thank you,
Fred

Glowsome · January 31, 2023, 1:38pm

you could try :

ldconfig -v | grep liblasso

On my CMK ( Rocky8, CRE 2.1.0P20) this gives:

liblasso.so.3 -> liblasso.so.3.13.0

Dont know if you have mlocate installed, but you could then ‘locate’ where the library is installed

locate lasso
/usr/lib64/liblasso.so.3
/usr/lib64/liblasso.so.3.13.0
/usr/share/doc/lasso
/usr/share/doc/lasso/AUTHORS
/usr/share/doc/lasso/COPYING
/usr/share/doc/lasso/NEWS
/usr/share/doc/lasso/README

Glowsome

techtuga · January 31, 2023, 2:10pm

both commands return empty results!

Glowsome · January 31, 2023, 3:00pm

If possible i would like to see the SAML-trace/conversation between IDP and SP.
Or atleast a snippet with specifically the signing algorithm used.

make a SAML-trace and look up/find the tag:

<ds:SignatureMethod Algorithm=

Glowsome

techtuga · January 31, 2023, 3:30pm

Here we go, i have anonymized some data.

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                ID="_59da02d4-9832-4e36-b4b3-0b1bad021509"
                Version="2.0"
                IssueInstant="2023-01-31T15:19:28.071Z"
                Destination="https://example.com/monitoring/mellon/postResponse"
                InResponseTo="_6D41A737633F2A697C87DA4911BFDE31"
                >
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/428a15ba-8cbf-4589-adf5-f266c725c32c/</Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
               ID="_36067ab3-df6e-4609-8ac9-51bf3f504600"
               IssueInstant="2023-01-31T15:19:28.071Z"
               Version="2.0"
               >
        <Issuer>https://sts.windows.net/428a15ba-8cbf-4589-adf5-f266c725c32c/</Issuer>
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
                <Reference URI="#_36067ab3-df6e-4609-8ac9-51bf3f504600">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                    <DigestValue>KJbF3YUyyhRyN4n8/dE/SfWNQtK+u0kye+qCx+7rt2Y=</DigestValue>
                </Reference>
            </SignedInfo>
            <SignatureValue>example</SignatureValue>
            <KeyInfo>
                <X509Data>
                    <X509Certificate>example</X509Certificate>
                </X509Data>
            </KeyInfo>
        </Signature>
        <Subject>
            <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">m5V3b4rIkHrSEaV4Jo36INZpNF8G2NWPOiUcVAkTiZw=</NameID>
            <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <SubjectConfirmationData InResponseTo="_6D41A737633F2A697C87DA4911BFDE31"
                                         NotOnOrAfter="2023-01-31T16:19:27.946Z"
                                         Recipient="https://example.com/monitoring/mellon/postResponse"
                                         />
            </SubjectConfirmation>
        </Subject>
        <Conditions NotBefore="2023-01-31T15:14:27.946Z"
                    NotOnOrAfter="2023-01-31T16:19:27.946Z"
                    >
            <AudienceRestriction>
                <Audience>https://example.com/monitoring/mellon/metadata</Audience>
            </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
                <AttributeValue>428a15ba-8cbf-4589-adf5-f266c725c32c</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
                <AttributeValue>3961545e-75cf-4ab3-ab17-50706c74e1b3</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
                <AttributeValue>Example</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
                <AttributeValue>https://sts.windows.net/428a15ba-8cbf-4589-adf5-f266c725c32c/</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
                <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
                <AttributeValue>Example</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
                <AttributeValue>Example</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
                <AttributeValue>example.example@example.com</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
                <AttributeValue>example@example.com</AttributeValue>
            </Attribute>
        </AttributeStatement>
        <AuthnStatement AuthnInstant="2023-01-19T08:21:32.319Z"
                        SessionIndex="_36067ab3-df6e-4609-8ac9-51bf3f504600"
                        >
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>

Glowsome · January 31, 2023, 4:26pm

Ok, that rules out the issue you referred to in the thread from mod_auth_mellon on Github.

As that was dealing with a SHA-1 signing, you are signing with SHA256

techtuga · January 31, 2023, 4:46pm

Not really, on the github post they also confirm that they use sha256.
It might be that somewhere in the Certificate Chain some Root or intermediate certificate uses sha1.

Which by the way is the case in Azure AD as you can see in this screenshoot:

mimimi · January 31, 2023, 5:42pm

I think this is related to the problem

github.com/latchset/mod_auth_mellon

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

opened 01:10AM - 18 Jan 23 UTC

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.

Glowsome · February 1, 2023, 12:55am

i would be very curiuos to see what happens when one installs the lasso package…

As in … will the system-package take over the tasks of the ‘shipped-with’ -version , and would it make a difference to the situation @techtuga is facing.

So @techtuga … is this something you could test out ?

BTW:

i did a quick Rocky 9.1 box setup and installed a CRE version ( current 2.1.0p20 )
then searched for lasso and found sources at:

/opt/omd/versions/2.1.0p20.cre/include/lasso/

Glowsome

Glowsome · February 1, 2023, 1:01am

The article/post was already posted in the topic-starter by poster.

techtuga · February 1, 2023, 8:50am

Thanks Mimimi and Glowsome for your replies.

@mimimi, yes probably it is related to that. I would really like to install a Centos 8 and the IdP we use to really confirm it is related.

@Glowsome, i did this already, and no it does not take over the shipped one.
Could you find put which version the shipped one is? I would really like to know in order to report this with Lasso.
Do you have means to connect the Rocky 9.1 to your IdP to reproduce it on your side too?

Fred

Glowsome · February 1, 2023, 11:31pm

My intent is to hook it up to my IDP, but lacking a bit of time atm.

Hope to do it over the weekend tho.

i did manage to find out which version of Lasso was/is shipped with it :

 0x000000000000000f (RPATH)              Library rpath: [/home/jenkins/workspace/cmk_210/nightly-cre/build-cmk-packages_11/git/omd/build/intermediate_install/lasso-2.7.0/lib]

Found this by executing and reading thru the output.

readelf -a -W /omd/sites/yoursite/lib/apache/modules/mod_auth_mellon.so | less

Also i looked up the Lasso Site, and a newer version is available (v2.8.0)

Glowsome

Glowsome · February 2, 2023, 12:26am

The thing that worries me most in the/this approach CMK has chosen is to incorporate the code in its own release.
Thus creating more dependancies.

Now i’m not a coder, but i would have gladly opted for an approach where dependancy of both the Lasso and mod_auth_mellon -package were made in the CMK-package.
IMHO this would create a more flexible setup-way, instead of incorporating a static version to ship with it.

Glowsome

Glowsome · February 2, 2023, 12:48am

@techtuga

if i encounter the same issue on my testbox, i’ve already hypothisized a different approach, and maybe if you have more time you could test it ?

Install both Lasso and mod_auth_mellon packages from repo
rename the mod_auth_mellon.so placed in /omd/sites/yoursite/lib/apache/modules/
symlink the /usr/lib64/httpd/modules/mod_auth_mellon.so to /omd/sites/yoursite/lib/apache/modules/

This would as far as i can tell cut loose the shipped part of both lasso and mod_auth_mellon, and would start using the (system-)packages.

If the behaviour stays the same it would give an environment where we could even experiment with Lasso 2.8.0 (compiling ourselves) via https://lasso.entrouvert.org/download/

Glowsome

techtuga · February 2, 2023, 3:33pm

@Glowsome

Hi,
So indeed i had time to:
1.Install both package from repo, rename and symlink it to the new packages. No success, same error.
2.Compile and symlink to the newest lasso version 2.8.0. No success, same error.
3.Open a support ticket with lasso which can be found here: Support #74121: Lasso Error 400 while receiving SAML response from AzureAD - Lasso - Redmine Entr'ouvert

Would really appreciate if you could try it on your 9.1 based box in order to reproduce this issue.
Btw it makes possibly only sense if your IdP is AzureAD or Google Workspace IdP as mentioned in the other Github thread.

Br,
Fred

Glowsome · February 2, 2023, 11:45pm

Well i dont have those IDP’s , i use a NetIQ IDP.

If you read the documentation about SAML on CMK theres a section specifically for NetIQ.
The sample auth.conf is what i wrote ( with all its comments/explanations) – with the missing IF-clause

Glowsome