Error creating SP metadata when adding X509 certificate for encryption

Lipscomb, Gary glipscomb at
Thu Mar 1 05:49:21 EST 2018

I've modified the SP's metadata to use the KeyValue element to add the public key. I don't know if they have changed the padding from PKCS1.5

   <md:KeyDescriptor use="encryption">
      <ds:KeyInfo xmlns:ds="">

Shibboleth is now happy but the SP vendor is now saying 

" The last errors that you received when testing the SSO connection means that the encrypted assertion that was sent was decrypted successfully but this decrypted assertion is again encrypted. Can you please create a SAML2 assertion and encrypted only once?"

------------------------ Error ------------------------
Error Code 8: Unable to decrypt the encrypted assertion.
------------------------ Error ------------------------
Error Code 8: We decrypted the assertion but the result is another encrypted assertion.

Is this at all possible?



-----Original Message-----
From: users [mailto:users-bounces at] On Behalf Of Cantor, Scott
Sent: Tuesday, 27 February 2018 12:48 PM
To: Shib Users <users at>
Subject: RE: Error creating SP metadata when adding X509 certificate for encryption

> I'm a bit confused. Are you saying even if I had a valid certificate not using the
> PKCS 1.5 in the SP metadata it wouldn't be used.

Certificates do not "use" RSA methods like PKCS 1.5. OAEP and PKCS1.5 are padding methods used when encrypting AES keys with RSA public keys. The certificate has nothing to do with this, it's merely a way of communicating a public key to begin with.

I don't recall exactly what it will do when there's an EncryptionMethod algorithm included that is barred. It may fall back to the OAEP padding method that's not broken or it may give up and assume the SP doesn't support anything else. I thought it did the latter, but you're not getting far enough to tell.

I simply was observing that they don't know what they're doing even more than was already noted and that using that metadata as is might not work even if the certificate weren't broken.

-- Scott

For Consortium Member technical support, see
To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list