CRM 2011 - IFD / ADFS Error - Relying Party Certificate was not found RRS feed

  • Question

  • Hi guys,
    I've spent the past two days trying to get IFD using Claims Auth with ADFS 2.0 working.

    I've followed the implementation guide, and various video tutorials on YouTube, but cannot get it working. All the steps upto to this point work correctly, I can access the metadata URL etc., but when I try to browse to my organisation I get the error in my following post.
    I have done some googling and really can't find anything that can suggest a fix. This is a very simple setup, with CRM and ADFS installed on the same machine (CRM on https port 444, and ADFS on the default website (443))
    Any ideas?

    Friday, April 29, 2011 6:52 AM

All replies

  • Server Error in '/' Application.



    Relying Party Certificate was not found.


    An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: Microsoft.Crm.CrmSecurityException: Relying Party Certificate was not found.

    Source Error:

    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

    Stack Trace:

    [CrmSecurityException: Relying Party Certificate was not found.]
      Microsoft.Crm.Authentication.Claims.ClaimsUtility.GetServiceConfiguration() +902
      Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.SetDefaults() +256
      System.Web.HttpApplication.InitModulesCommon() +124
      System.Web.HttpApplication.InitInternal(HttpContext context, HttpApplicationState state, MethodInfo[] handlers) +1655
      System.Web.HttpApplicationFactory.GetNormalApplicationInstance(HttpContext context) +374
      System.Web.HttpApplicationFactory.GetApplicationInstance(HttpContext context) +178
      System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +371
    Friday, April 29, 2011 6:52 AM
  • I"m having the same issue, sts and crm on the same server, walked through the latest intallation guide but getting the same error you posted.  I haven't been able to google up anything on the issue.
    Jay Quincy Allen
    Tuesday, May 3, 2011 7:09 PM
  • Hi,

    What kind of certificate are you using for your claims encryption certificate? Is that certificate in the Local Computer's Trusted Root Certification Authorities store?

    Please note that we recommend purchasing a certificate that is signed by a trusted certification authority for security reasons. Also, I assume that you are looking at the guide on Configuring Claims-based Authentication? If not, check it out since it has some good information on certificates.

    Let us know if this helps.


    Thursday, May 5, 2011 8:06 PM
  • We had a similar issue and were able to track it down using the trace files.  Here is what I would recommend:

    1. See if you can access the CRM authentication endpoint.  You tell it what this is in the IFD config in Deployment Manager.  The default is https://auth.yourdomain.com:444 and the full URL to test it would be https://auth.yourdomain.com:444/FederationMetadata/2007-06/FederationMetadata.xml.  You should see some XML.  If you get an error, which I would expect based on the info you provided, then you will want to run a trace to get more details.
    2. Install the CRM Diag Tool for 2011, available here:  http://mscrmtools.blogspot.com/2011/04/new-tool-crmdiagtool-2011.html.  Just click the big zip icon to go to the download page.
    3. Run the Diag tool and enable Tracing.
    4. Goto the CRM auth endpoint again (from step 1) to get the error.
    5. Disable tracing in the Diag tool
    6. Open the trace file folder.
    7. You want to look at the trace file with <servename>-w3wp-CRMWeb in it.  Go to the end of the file and search Up for "Level: Error" (without the quotes).  Or you can just browse around.

    Hopefully this will give you some indication of what's going on.  It may only have the Relying party cert error in there but you might be able to determine your next action based on what happened right before that.  For example, the check that is likely failing is one which searches the MSCRM_CONFIG database for a Relying Party Cert.  This was the case in our scenario.  Our issue turned out to be that CRM only supports 128 characters for the certificate name.  So the claims-based authentication failed (Deployment Manager crashed) and it never put the cert in there.  If you would like all of the gory details on what the symptoms of that are then please see http://frankwilsonv3.blogspot.com/2011/05/crm-2011-ifd-certificate-name-can-only.html



    Friday, May 27, 2011 8:44 PM
  • Hey Frank,

    I just read your blog posting regarding the 128 character limit on Certificate Names for Claims configuration.

    You're quite right, mostly.  The Deployment Manager does indeed use Metadata to determine the maximum allowable length of the Name column in the Certificates table, but it isn't specified in code, but in a Metadata column - it must be cached when the Deployment Manager snap-in loads or something similar.

    Agreed, we need a hotfix and/or rollup patch because it's rather ridiculous that certificates from a major cert issuer (RapidSSL is the one we had an issue with also) are incompatible.

    If you really want to "hack" your way around this issue, you need to run the following in the MSCRM_CONFIG DB:


       ConfigurationMetadataXml =
          CAST(ConfigurationMetadataXml AS NVARCHAR(MAX)),
          '<Description>Name of the Certificate</Description><Type>nvarchar</Type><Length>128</Length>',
          '<Description>Name of the Certificate</Description><Type>nvarchar</Type><Length>256</Length>'
    I logged a Fix Request on Microsoft Connect regarding the Cert Name length issue - track it down and vote for it, if you'd like to see it changed.

    NB: This is *highly* unsupported, but I can attest from personal experience on 2 separate Claims-based authentication configured CRM deployments, that it does work.


    --pogo (pat) @ pogo69.wordpress.com
    Saturday, May 28, 2011 12:23 AM
  • Thanks for the help on this.  I have tried your suggestion and it appears to have resolved the issue.  I also updated my blog and noted your fix there.




    Wednesday, June 1, 2011 3:43 PM
  • Hi this databasehack is not an good Idea. I am sure it will bring you some other issues later when you install the next rollup....

    But as it is hard to get an certificate less 128 characters from your third party provider.
    Youcan create your  own self signed certificate for token signing.
    In this case you can specify the length by yourself, makes it much easier.

    Use your wildcard certificate for CRM IIS Server and also for ADFS 2.0 You only need to use the self signed certificate when you

    have to add the certificate during the claims wizard...


    I posted 1x solutions: www.dynamics-crm-2011.de/.../adfs-and-crm-2011-troubleshooting

    Saturday, June 4, 2011 6:55 PM
  • Hi Pat.

    This fixed our issue as well. Thankyou

    Don't really know what is the 128 charcater limit though? Our name of certificate along with SAN's is less than 128 characters.


    Tuesday, June 28, 2011 1:50 AM
  • update rollup 4 for crm 2011 fixes this issue.



    i would stay away from modifying the database....

    • Proposed as answer by Jason Madigan Thursday, May 31, 2012 6:37 PM
    • Unproposed as answer by Jason Madigan Thursday, May 31, 2012 6:37 PM
    • Proposed as answer by Jason Madigan Thursday, May 31, 2012 6:42 PM
    Thursday, November 17, 2011 10:21 PM
  • Rollup 8 is now out so nobody should be modifying the database.  However we just ran into this issue.  We had rollup 6 and rollup 8.  Verified that the name column in the certificate database is over 512 (forgot the exact value).  Tried a few things.

    Our issue was that the wildcard certificate that we used is expiring soon so we renewed it and installed it.  But we didn't remove the expiring.  This was on our dev server so we never really noticed if there was an issue until we installed rollup 8. 

    Our solution was pretty simple.  In the database table for the certificates there is a field called "StoreFindType" and the value for our wildcard cert was "FindBySubjectDistinguishedName".  Double checked and both certs (expiring and renewed) had the exact same name.  Just removed the expiring certificate from the local personal store and it came right back up.

    Thursday, May 31, 2012 6:42 PM