Troubleshooting: Failed to Generate XML Signature on a SAML Assertion

Version Affected: All
 
 

Overview

Users see a login error on a SAML realm, and the audit log or application logs show an entry similar to Message="SAML20IdPInit.PageLoad: Error in SSO service, Failed to generate XML signature.", or an exception ending in at ComponentSpace.SAML2.Utility.XmlSignature.Generate(...).

This has two independent causes:

• See Cause 1 - One of the values being sent as an Extended SAML Attribute contains a character that is not valid in XML.
• See Cause 2 - The realm's SAML Signing Algorithm setting does not match the signing certificate's actual SHA version, or the certificate's Cryptographic Service Provider (CSP) does not support SHA2 signing.

Check each cause below. The causes are not related, so a fix for one cause will not resolve another cause.

 

In this article

• Cause 1: Invalid Character in an Extended SAML Attribute
• Cause 2: SHA1/SHA2 Certificate and Signing Algorithm Mismatch

Cause 1: Invalid Character in an Extended SAML Attribute

One of the values being sent as an Extended SAML Attribute contains a character that is not valid in XML — for example, a control character — which prevents the SAML assertion from being signed. The underlying exception looks similar to:

System.Xml.XmlException: '♫', hexadecimal value 0x0E, is an invalid character.
   at System.Security.Cryptography.Xml.SignedXml.BuildDigestedReferences()
   at ComponentSpace.SAML2.Utility.XmlSignature.Generate(...)

In the case that produced this error, the attribute being sent was thumbnailPhoto — a binary photo field in Active Directory — and its value contained a character that is invalid inside an XML document.

Resolution 1:

Check each Extended SAML Attribute the realm sends, and inspect the Active Directory value it pulls from for invalid or control characters — this is especially likely for attributes that hold binary or free-text data, such as thumbnailPhoto. Remove the attribute from the realm's configuration, or correct the underlying Active Directory value, so the SAML assertion no longer includes an invalid character.

Cause 2: SHA1/SHA2 Certificate and Signing Algorithm Mismatch

The realm's SAML Signing Algorithm setting must match the SHA version the signing certificate actually supports. A SHA1 certificate does not work if this setting is SHA2. A SHA2 certificate works with either setting, but only if its Cryptographic Service Provider (CSP) is Microsoft Enhanced RSA and AES Cryptographic Provider — an older or incompatible CSP will still fail SHA2 signing even though the certificate itself is SHA2.

The screenshot above shows the SAML Signing Algorithm setting, alongside the realm's other SAML options.

Resolution 2:

1. Check the signing certificate's properties to see whether it is a SHA1 or SHA2 certificate — its Signature algorithm field reads sha1RSA for SHA1, or sha256RSA for SHA2/SHA256.

The screenshots above show an example SHA1 certificate and an example SHA2 certificate.

2. If the certificate is SHA1, set the realm's SAML Signing Algorithm to SHA1 — SHA2 will not work with a SHA1 certificate. If the certificate is SHA2, either SHA1 or SHA2 can be selected.
3. If the certificate is SHA2, the correct signing algorithm is selected, and the error still occurs, confirm the certificate's CSP supports SHA2 signing. Open an elevated Command Prompt and run:

certutil -store my > c:\temp\certinfo.txt

This writes the appliance's personal certificate store details to the file. The output must show Provider = Microsoft Enhanced RSA and AES Cryptographic Provider for SHA2 signing to work correctly.

The screenshot above shows this output when the CSP is correctly configured.

4. If the CSP is incorrect, export the certificate together with its private key as a PFX file, then re-import it with the correct CSP using certutil:

certutil -csp "Microsoft Enhanced RSA and AES Cryptographic Provider" -importPFX -p "PASSWORD" "PATH_TO_CERT.pfx"

Replace PASSWORD with the PFX file's export password, and PATH_TO_CERT.pfx with the path to the exported file.

Changing the CSP this way should only be done directly on Windows Server 2012 R2 — Windows Server 2008 R2 does not handle changing a certificate's CSP correctly. If the appliance is running 2008 R2, perform the CSP change on a separate Windows Server 2012 R2 machine instead: export the certificate and private key as a PFX from the appliance, copy it to the 2012 R2 machine, run the certutil -csp ... -importPFX command there, then export the certificate and private key again from that machine and copy it back to the appliance for import.

Special Considerations

Before deleting an existing certificate to reimport it with a different CSP, back up the certificate and its private key. Reimporting with certutil -importPFX does not guarantee the new import will overwrite a certificate that already exists in the store. For more on CSPs and algorithm support, see Microsoft's documentation.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.