key algorithm didn't match ('AES' != 'RSA') failed to decrypt assertion: Unable to locate an encrypted key.

Lipscomb, Gary glipscomb at csu.edu.au
Wed Sep 19 04:21:03 EDT 2018 

Nate,


If I change the entityID for the metadata for this SP on the IDP and reload it I get a not registered for this service message when attempting to login.  So there doesn't appear to be another matching entityID.


Haven't tried samltest.id - will do tomorrow.


We also do an automated (puppet) build of the SP's metadata  using the sp's public certificates and get the same results.

I've double checked that was is in the .pem files matches what is in the metadata as well.


regards


Gary.

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Nate Klingenstein <ndk at sudonym.me>
Sent: Wednesday, 19 September 2018 4:09 PM
To: Shib Users
Subject: Re: key algorithm didn't match ('AES' != 'RSA') failed to decrypt assertion: Unable to locate an encrypted key.

Gary,

I'm a little uncertain about this, but it looks to me like a plain key-in-metadata and key-in-configuration mismatch.  I'm unsure because of:

http://shibboleth.1660669.n2.nabble.com/Unable-to-locate-an-encrypted-key-td5557791.html<http://antispam.csu.edu.au:32224/?dmVyPTEuMDAxJiY2NzU0OTNkY2JiODNlNDJmNT01QkExRTg0OF84NTk2MF8zNDk4XzEmJmI5MWE2MmVmNzY3ZTA2MT0xMzMzJiZ1cmw9aHR0cCUzQSUyRiUyRnNoaWJib2xldGglMkUxNjYwNjY5JTJFbjIlMkVuYWJibGUlMkVjb20lMkZVbmFibGUtdG8tbG9jYXRlLWFuLWVuY3J5cHRlZC1rZXktdGQ1NTU3NzkxJTJFaHRtbA==>

Anyway, AFAIK the generator and validator both evaluate the same configuration directives, thus pulling the same keys, so it's hard to explain why the IdP is using the wrong key unless the same SP entityID is registered and loaded somewhere else in the IdP and taking precedence.

Have you tried a sanity check using a service like SAMLtest at samltest.id<http://antispam.csu.edu.au:32224/?dmVyPTEuMDAxJiYzZTE2ZDE5Y2I3OWFmMjcyNT01QkExRTg0OF84NTk2MF8zNDk4XzEmJjRjZWU0MzRmMzc2ZjYyMz0xMzMzJiZ1cmw9aHR0cCUzQSUyRiUyRnNhbWx0ZXN0JTJFaWQ=>?  You can upload the SP metadata directly from /Shibboleth.sso/Metadata if the site is publicly exposed.

Otherwise, my next step would be comparing the encryption key sent in the SAML assertion to the encryption keys in the metadata and the configuration and seeing where the discrepancy is.

Probably going to be corrected by morning,
List.

On Tue, Sep 18, 2018 at 8:20 PM, Lipscomb, Gary <glipscomb at csu.edu.au<mailto:glipscomb at csu.edu.au>> wrote:
Hi list,

Shibboleth SP v3.0.2
Shibboleth IDP v3.3.3
RHEL 7

This is our first clean install of a new  SP v3.0.2 and trying to resolve the above issue.  All the rest have been upgrades and still use the v2 configuration.

Metadata sent to IdP generated from /Shibboleth.sso/Metadata. The public keys in the metadata for signing and encryption match the appropriate certs on the SP.
Where do I look next ?

Regards

Gary

Shibd.log

   2018-09-19 11:58:10 INFO Shibboleth.Application : building CredentialResolver of type Chaining...
   2018-09-19 11:58:10 INFO XMLTooling.CredentialResolver.Chaining : building CredentialResolver of type File
   2018-09-19 11:58:10 INFO XMLTooling.SecurityHelper : loading private key from file (/etc/shibboleth/sp-signing-key.pem)
   2018-09-19 11:58:10 INFO XMLTooling.SecurityHelper : loading certificate(s) from file (/etc/shibboleth/sp-signing-cert.pem)
   2018-09-19 11:58:10 INFO XMLTooling.CredentialResolver.Chaining : building CredentialResolver of type File
   2018-09-19 11:58:10 INFO XMLTooling.SecurityHelper : loading private key from file (/etc/shibboleth/sp-encrypt-key.pem)
   2018-09-19 11:58:10 INFO XMLTooling.SecurityHelper : loading certificate(s) from file (/etc/shibboleth/sp-encrypt-cert.pem)
   2018-09-19 11:58:10 INFO Shibboleth.Listener : listener service starting

Snip

   </xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></saml2:EncryptedAssertion></saml2p:Response>
   2018-09-19 11:58:35 DEBUG OpenSAML.MessageDecoder.SAML2 [2] [default]: extracting issuer from SAML 2.0 protocol message
   2018-09-19 11:58:35 DEBUG OpenSAML.MessageDecoder.SAML2 [2] [default]: message from (https://redacted/idp/shibboleth)
   2018-09-19 11:58:35 DEBUG OpenSAML.MessageDecoder.SAML2 [2] [default]: searching metadata for message issuer...
   2018-09-19 11:58:35 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [2] [default]: evaluating message flow policy (replay checking on, expiration 60)
   2018-09-19 11:58:35 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [2] [default]: validating signature profile
   2018-09-19 11:58:35 DEBUG XMLTooling.TrustEngine.ExplicitKey [2] [default]: attempting to validate signature with the peer's credentials
   2018-09-19 11:58:35 DEBUG XMLTooling.TrustEngine.ExplicitKey [2] [default]: signature validated with credential
   2018-09-19 11:58:35 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [2] [default]: signature verified against message issuer
   2018-09-19 11:58:35 DEBUG XMLTooling.CredentialCriteria [2] [default]: usage didn't match (4 != 3)
   2018-09-19 11:58:35 DEBUG XMLTooling.CredentialCriteria [2] [default]: key algorithm didn't match ('AES' != 'RSA')
   2018-09-19 11:58:35 ERROR Shibboleth.SSO.SAML2 [2] [default]: failed to decrypt assertion: Unable to locate an encrypted key.
   2018-09-19 11:58:35 WARN Shibboleth.SSO.SAML2 [2] [default]: error processing incoming assertion: A valid authentication statement was not found in the incoming message.


Shibboleth2.xml

        <CredentialResolver type="Chaining">
          <CredentialResolver type="File" key="sp-signing-key.pem" certificate="sp-signing-cert.pem" use="signing" extractNames="false"/>
          <CredentialResolver type="File" key="sp-encrypt-key.pem" certificate="sp-encrypt-cert.pem" use="encryption" extractNames="false"/>
        </CredentialResolver>

Permissions
-rw-r--r--. 1 shibd shibd 1493 Sep 19 11:16 sp-encrypt-cert.pem
-rw-------. 1 shibd shibd 2484 Sep 19 11:16 sp-encrypt-key.pem
-rw-r--r--. 1 shibd shibd 1493 Sep 19 11:16 sp-signing-cert.pem
-rw-------. 1 shibd shibd 2484 Sep 19 11:16 sp-signing-key.pem

|   ALBURY-WODONGA   |   BATHURST   |   CANBERRA   |   DUBBO   |   GOULBURN   |   MELBOURNE   |   ORANGE   |   PORT MACQUARIE   |   SYDNEY   |   WAGGA WAGGA   |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.
Charles Sturt University in Australia The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018
Consider the environment before printing this email.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg<http://antispam.csu.edu.au:32224/?dmVyPTEuMDAxJiYzOTBlYzA5OGU1OWJiMzY0ND01QkExRTg0OF84NTk2MF8zNDk4XzEmJjE4Y2ViMmZmODYzZWU3OD0xMzMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZ3aWtpJTJFc2hpYmJvbGV0aCUyRW5ldCUyRmNvbmZsdWVuY2UlMkZ4JTJGY29GQUFn>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

More information about the users mailing list