ADFS - Certificate not unique

Question

I have created several applications that use SAML2 authentication. These applications (including SalesForce) often share the same domain (ie: reports.application.com, portal.application.com, etc) but are NOT part of a single application or even on the same stack. Some subdomains lead to SalesForce, some to other applications.

The problem is that ADFS reports the "Certificate is not unique" and refuses to allow applications to be registered in the ADFS database because the certificates are the same. This is especially troublesome with SalesForce.

I'm not sure how to work around this.

Edit: It is important to note that nearly all of these applications are SAML2 and not ADFS.

Answer 1

I'm slightly confused by the statement "It is important to note that nearly all of these applications are SAML2 and not ADFS." Did you mean "It is important to note that nearly all of these applications are SAML2 and not WS-Fed"?

How do these applications authenticate with ADFS? Do you have some kind of third-party stack?

Why do these applications have a certificate? Is it because the request are signed or the SLO is signed or what?

If some of the applications don't actually need a certificate you can remove it from the metadata.

Answer 2

This issue can be resolved by applying the roll-up 3 for ADFS 2.0 ( http://support.microsoft.com/kb/2790338)

It lists the known issues and the Hot Fix. Specific to Salesforce , we get the following issue (described in Rollup 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 prevents multiple relying parties from using 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.

Note: After applying update rollup 3, you will need to manually run a script(as described below) to make the fix for this issue work.

Window Internal Database:

For issue 3, this hotfix installs a PowerShell script that is named "PostReleaseSchemaChanges.ps1" into the "%program files%\active directory federation services\sql" folder.

If you are using Windows Internal Database (WID) as the AD FS 2.0 configuration database, then after you apply this hotfix, you must manually execute the PostReleaseSchemaChanges.ps1 PowerShell script first on the secondary federation servers in the farm, and then on the primary federation server.

Note: You might hit an error "the execution of scripts is disabled on this system." To overcome this, you can try running the following command in the powershell(for Windows Server 2008 R2):

Set-ExecutionPolicy RemoteSigned

If you still face this issue, Refer to the below StackOverflow post: PowerShell says "execution of scripts is disabled on this system."

SQL Server:

If you are using a SQL Server database as the AD FS 2.0 configuration database, you must download and execute the RelaxedRequestSigningCertsv2.sql script against SQL Server database.

To execute this script, run the following cmdlet by using the Sqlcmd utility: Sqlcmd -S -i RelaxedRequestSigningCertsv2.sql Or, follow these steps to run the cmdlet by using SQL Server Management Studio:

Connect to the SQL Server database that has the AD FS 2.0 configuration database.
Create a new SQL query.
Paste the contents of the RelaxedRequestSigningCertsv2.sql file into the query, and then execute the query.