IdP "Unable to encrypt assertion"

[Yeargan, Yancey]

Yes, that metadata (other than redactions to conceal the vendor's identity) is verbatim from the SP metadata file we are using with our IdP (Shibboleth IdP v2.3.2).

Concerning a possible entityID mismatch, if I override SAML2SSOProfile with encryptAssertions="never" for this SP, then the IdP responds by sending a signed assertion containing an attribute statement to the SP and the vendor confirms that the SP received the response and was able to extract the attribute with no errors. For the sake of being thorough, here is the SAML request from the debug logs. I verified that the entityID matches the SP metadata.

08:51:27.131 - DEBUG [PROTOCOL_MESSAGE:112] - 
<?xml version="1.0" encoding="UTF-8"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://proofing.[redacted]/saml/unt" Destination="https://sso.unt.edu/idp/profile/SAML2/Redirect/SSO" ForceAuthn="false" ID="s2bb6b184b6a1ca93a4554be3c9447ecbedaf53a98" IsPassive="false" IssueInstant="2011-09-26T13:51:27Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">[entityID redacted]</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" SPNameQualifier="[redacted]" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"/>
<samlp:RequestedAuthnContext Comparison="exact" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
      <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
   </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>


Concerning the SP certificate itself (possibly being a non-RSA key or something), here [below] is the output from 'openssl x509 -text' on the certificate data contained in the SP metadata.

If not the SP metadata format, the SP certificate format, or an entityID mismatch, what does that leave?

What should I be looking for in debug logs? I keep looking over them and nothing is sticking out yet. My searches of the list archive have not borne any fruit yet.


====================
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1276694008 (0x4c18cdf8)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Entrust, Inc., OU=www.entrust.net/rpa is incorporated by reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification Authority - L1C
        Validity
            Not Before: Sep 17 15:29:31 2010 GMT
            Not After : Jan  1 15:59:30 2014 GMT
        Subject: [redacted]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    [binary data]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.entrust.net/level1c.crl

            Authority Information Access: 
                OCSP - URI:http://ocsp.entrust.net

            X509v3 Certificate Policies: 
                Policy: 1.2.840.113533.7.75.2
                  CPS: http://www.entrust.net/rpa

            X509v3 Authority Key Identifier: 
                keyid:1E:F1:AB:89:06:F8:49:0F:01:33:77:EE:14:7A:EE:19:7C:93:28:4D

            X509v3 Subject Key Identifier: 
                CA:62:14:B6:65:03:B8:45:AF:A3:52:1C:20:4D:71:99:2B:9A:75:A2
            X509v3 Basic Constraints: 
                CA:FALSE
    Signature Algorithm: sha1WithRSAEncryption
        [binary data]
====================




On Sep 26, 2011, at 12:25 PM, Cantor, Scott wrote:

> If that's the metadata you're using, then it would work, unless the log
> includes some low level indication of why encryption would have failed. I
> would speculate that the cert is unusual in some fundamental way (not an
> RSA key for example), or the entityID isn't correct in the request or
> something like that.
> 
> -- Scott