Issue with ADFS 2.0 Proxy Certificates and Communication
-
Monday, March 22, 2010 5:18 PM
Hello,
We're trying to setup a ADFS 2.0 lab environment and we're having trouble getting the proxy and federated server communicating with each other. I have setup the proxy on both ends and I imported the client authentication certificate into the proxy certificates on the federated server. Here are some questions that I have:
Do I need to import the public key from the federated server into the proxy server?
Do I need to exchange any certificates between proxy servers in the two domains?
I am getting the following error below, when the ADFS Proxy service starts up - any ideas?
The Federation Service Proxy was not able to retrieve the list of endpoints from the Federation Service at "NameOfFederatedServer". The error message is 'The HTTP request was forbidden with client authentication scheme 'Anonymous'.'.
All Replies
-
Monday, March 22, 2010 6:37 PM
Most likely case is that proxy identity certificate is not root and peer trusted on STS machine. Unfortunatelly this failure is a result of downlevel WCF failure in ADFS code - so there is not much diagnosability in this case.
Following steps should fix the failure. (1) Go to proxy machine and export proxy certificate? The proxy certificate should be dropped inside the localmachine\my store. (2) Import proxy certificate to trusted root and trusted people store on STS machine.
We know that's a problem and we hope to improve this deployment case in RTM.
-
Monday, March 22, 2010 8:40 PM
Thank you for your help...
I added the "Proxy Identity Certificate" to the Trusted Root and Trusted People on the Federated Server and that fixed the problem of the error upon startup of the ADFS Proxy service. We are still having a problem though trying to add ADFS1-FEDSRV as a claims provider on ADFS2-FEDSRV. We get the following error:
An error occurred during an attempt to read the federation metadata. Verify that the specified UTL or host name is a valid federation metadata endpoint. Error message: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
During the "Claims Provider Trust Wizard", I am inputing the name name of the Federation Server, which points to the Proxy server IP address in the local hosts file. I have tried adding the IIS SSL certificate from ADFS1-PROXY into ADFS2-FEDSRV as a Trusted Root and Trusted People, but this did not help.
Also, if I manually go to the URL of https://adfs1-fedsrv.adfs1.com/FederationMetadata/2007-06/FederationMetadata.xml in Internet Explorer from ADFS2-FEDSRV, I initially get a warning that the SSL cert is issued for a different computer name than what's in the URL (because it is redirecting to the proxy IP address). If I go past this warning in Internet Explorer, it then shows me the contents of the XML file.
Do you have any ideas/suggestions for getting this claims provider setup? Do I need to exchange any additional certificates between domains (ADFS1 and ADFS2)?
-
Tuesday, March 23, 2010 1:21 AM
ADFS uses same verification procedure for SSL certificates as IE - so once you make sure that IE does not show warning anymore you should be able to import metadata to ADFS.
-
Wednesday, May 23, 2012 10:46 AM
hi any one got solution to the error "An error occurred during an attempt to read the federation metadata. Verify that the specified UTL or host name is a valid federation metadata endpoint. Error message: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel." ?
please share here...
thanks,
yes.sudhanshu
yes.sudhanshu
http://bproud2banindian.blogspot.com
http://ms-crm-2011-beta.blogspot.com -
Thursday, June 28, 2012 6:45 AM
hi any one got solution to the error "An error occurred during an attempt to read the federation metadata. Verify that the specified UTL or host name is a valid federation metadata endpoint. Error message: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel." ?
My problem was that the certificates bound to IIS https port 443 was self signed. My solution was to replace the certificates with domain server certificates. Problem solved for me, anyway.
-
Wednesday, August 08, 2012 3:47 PMhi I have the same problem, could you please describe closer how to use domain server certificates?
-
Thursday, October 11, 2012 7:47 AM
I think this happens because you're not using a wildcard trusted certificate! The certificate assigned to the CRM IIS website needs to be *.yourdomain.com certificate otherwise it will fail.
I have the same issue because i'm using one SAN certificate crm.mydomain.com
Mohammed JH

