web
You’re offline. This is a read only version of the page.
close
Skip to main content
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics CRM (Archived) / Invalid provider type ...
Microsoft Dynamics CRM (Archived)

Invalid provider type specified

(0) ShareShare
ReportReport
Posted on by Miss Stacy 10

I have a virtualized CRM 2016 lab environment with a full server deployment (CRM, ADDS, DNS, IIS, SQL on the same Hyper-V machine) and a separate ADFS Hyper-V machine running on Windows Server 2016 on my local machine. I am using a self-signed wildcard certificate.

I am receiving this error when I navigate to the CRM endpoint (metadata URL) after configuring claims-based authentication.


The XML page cannot be displayed

Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.

The download of the specified resource has failed. Error processing resource 'internalcrm.crmdomain.com/federationm...


When I click on Refresh, the following page loads:

841488.Capture.PNG

*This post is locked for comments

I have the same question (0)
  • David Jennaway Profile Picture
    David Jennaway 14,065 on at
    RE: Invalid provider type specified

    The issue may be with the template you used for the self-signed certificate. I think you need to use the v2 template (rather than v3). See https://social.microsoft.com/forums/en-US/6f89faad-a0a4-4f2e-a76e-cefd56256f99/unable-to-browse-to-the-crm-federationmetadata-endpoint-after-configuring-claimsbased-auth  . Although it was written for CRM 2011, the same issue can apply to CRM 2016 

  • Sky_God Profile Picture
    Sky_God 24 on at
    Invalid provider type specified
    We had this for Dynamics 365 9.1 on-prem and ADFS where the CRM system would not load the CRM's FederationMetadata.xml and threw an event log 3005.
    Exception Type: CryptographicException
    Exception Message: Invalid Format Provider specified.
     
    We needed this working before we could proceed with ADFS + Claims renewal for the year.
     
    We had added private key permissions -- which is the usual issue with SSLs and CRM -- so that was not the problem.
     
    The reason is that the commercial SSL issued was not of type CAPI1, we had unknowingly been issued a CNG (Certificate Next Generation).
     
    In CRM and ADFS scenarios, the following applies:
    which takes one to this article
     
    We also checked the bit-length of the SSL to be 2048 bits, rather than 4096, but I don't think this was the issue as other 4096 bit-lengths have been used.
     
    We needed to generate another Key Signing Request with the legacy format specified as things have been updated somewhat SSL-wise.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Pallavi Phade – Community Spotlight

We are honored to recognize Pallavi Phade as our Community Spotlight honoree for…

Congratulations to the October Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics CRM (Archived)

#1
Community Member Profile Picture

Community Member 2

#1
UllrSki Profile Picture

UllrSki 2

#3
SC-08081331-0 Profile Picture

SC-08081331-0 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans