MSIS7613: The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration

Scenario

You are attempting to add a relying party (RP) trust to your Active Directory Federation Services (AD FS) 2.0 federation service (FS) and you get the following error:

image

Textually:

An error occurred during an attempt to access the AD FS configuration database.

MSIS7613: The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration.

Issue

The token signing certificate is already used in one of the other RP trusts.

AD FS expects and requires that each RP application utilise a unique token signing certificate.

Other FS do not however, and this is a bit of a common issue.  The workaround of removing the signing certificate is not a great solution and often the push back to get two certificates won’t be implemented (for good reason as there’s likely a whole raft of systems using it without issue).

Resolution

AD FS Update Rollup #3 (issue #3).  Here’s some verbiage from the KB:

Issue 3

Some relying parties require that signature certificates are applied to the relying party for SAML requests, as signature certificates provide a critical security validation function and are defined in the SAML 2.0 specification. AD FS 2.0 is capable of allowing unique signature certificates to be applied to a relying party trust, but it only allows the same certificate to be applied to one relying party trust per AD FS 2.0 farm. This restriction may allow multiple relying parties to use the same signing certificate for SAML requests. AD FS 2.0 update rollup 3 removes this restriction and allows multiple relying parties to use the same signing certificate for SAML request.

Post-update configuration

Note however that simply applying the update rollup doesn’t allow you to implement multiple relying party trusts with the same certificate.  After applying the update you have to run the script PostReleaseSchemaChanges.ps1.

The script is located under the AD FS binaries directory:

C:\Program Files\Active Directory Federation Services 2.0\SQL

If you have a WID backend you need to run the script on the primary FS.  You can run it on any FS if you have a SQL backend.  Before running the script load the AD FS PowerShell snapin, e.g.:

cd "$env:programfiles\active directory federation services 2.0\sql"
Add-PSSnapin microsoft.adfs.powershell
.\PostReleaseSchemaChanges.ps1

After running the script – which runs SQL scripts and outputs a lot of text to the shell – you can create RP trusts with the same signing certificate.

Here I create two RP trusts to Oracle Taleo with the same certificate, as evidenced from the highlighted thumbprint.

image

Advertisements

About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in AD FS, Troubleshooting and tagged , , , , , , . Bookmark the permalink.

5 Responses to MSIS7613: The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration

  1. Pingback: (2013-02-15) Update Rollup 3 For ADFS v2.0 Has Been Released « Jorge's Quest For Knowledge!

  2. Pingback: Update Rollup 3 for Active Directory Federation Services (AD FS) 2.0 | Yet another identity management blog

  3. Pingback: Windows Server 2012 – ADFS 2.1 – Erro MSIS7613:The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration | How to?

  4. Michele says:

    Hi, I’ve seen from screenshots in this post that you have already configured Taleo as a Relying Party. I have posted a question about this. do you have any suggestion?
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/0ab640cd-1fa9-444b-9566-eb8217c7fe43/adfs-taleo-relying-party-configuration?forum=winserverDS

    • It’s been ages since I did the Taleo trust but I recently saw something very similar to what you describe with ChromeRiver. In this case it was a case of nomenclature mismatch. They asked for x and y and we provided y and z. As a result the URLs and identifiers were wrong on both sides. The issue here is that you are using metadata – all should be good with regards specific configuration in this instance.

      My advice: decrypt the SAML and drop it into Visual Studio or your preferred XML editor and take a good look at the properties and claims and map these against what is configured in Taleo. Look to the IdP identifier and authentication URLs in particular and then take a good look at your claim rule, although the HTTP 500 error usually indicates an actual configuration issue – bad claims/assertions would yield a better error.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s