An InfoPath 2007 form deployed in 2010 gave repeated errors on opening, including:
“You do not have permission to access a web service.”
“The root of the certificate is not a trusted root authority.”
The InfoPath form in question was an administrator-approved form which called a SharePoint web service called GetUserProfileByName in order to pre-populate several fields with the current user’s data. Permissions were checked and the data connection (UDCX) files were examined for errors, including incorrect URLs. The form threw no errors in SharePoint 2007. A search for the correlation ID in the Windows Application Event logs revealed an error regarding the main wildcard SSL certificate for the site. This certificate had a valid date range and was working correctly to authenticate https traffic.
Several blogs (Share-n-dipity Eric Kraus’ SharePoint/.NET Blog ) pointed out that SharePoint 2010 has its own trusted authority store, separate from the Windows certification registry; these blogs were focused on the error when using claims authentication. This forum: InfoPath Form Errors after In-Place Upgrade from MOSS 2007 to SharePoint 2010 was more InfoPath specific. By default, only the “local” trust resides here (Central Admin>Security>Manage Trusts), but additional certificates may be added. Do not delete the “local” connection; it is used internally by SharePoint.
“I trust you, baby. I just don’t trust your friends.”
The error in the event logs meant SharePoint was complaining that the root of the authentication chain was not listed as a trusted certificate-issuing authority in the SharePoint trusts store. In other words, SharePoint was saying, “This document looks legitimate, but are you sure the person who gave it to you was legit?” Registering the issuing authority’s certificate verifies that the authority is a trusted source. If your SSL cert includes a certificate hierarchy, all the certificates in the hierarchy must be listed in the managed trust store of SharePoint 2010.
Let’s Play “Find the Cert!”
To identify the issuing authority certificate(s) in use, find your SSL cert in the certification management console on the server on which the certificate has been installed. (Run > certmgr.msc) You may have to look under the Personal folder to find the SSL certificate (or if someone else installed the certificate, it may be under their Personal folder when logged in under their profile). In our case, the SSL cert had a 3 tier hierarchy. We noted the certificate names and exported each certificate by right clicking the certificate in the list and exporting it using the default settings to produce a .cer file. We then uploaded them to the Managed Trusts site in Central Admin, giving each a reasonable name and providing no other optional info.
One thing to note: the name displayed in the certificate hierarchy is not the name listed in the certificate list, but rather, the “friendly” version of that name. In our case, they were nothing alike, and we had a difficult time locating one of the certificates because the friendly name did not display in the regular screen display. To see the heirachical name, the user must scroll several fields to the right.
Additionally, the listing of certificates in SharePoint’s Managed Trusts center was required with this InfoPath form because the form was an administratively-deployed form containing code. InfoPath forms which do not contain code and which are published to SharePoint by users will likely not encounter this problem.