1

I'm having certificate issues when trying to configure one Farm to consume the Managed Metadata service of another. This is a lab environment so I don't want to go buying any proper certificates. I get stuck at the point where I try to setup the Connection proxy on the consumer farm.

I've been using this blog post as a guide but to no avail.

Farm A - Publishing Farm. Lab server, any certificates are self-signed.

Farm B - Consuming Farm. Lab server, any certificates are self-signed.

Here's what i've done so far:

  • Farm A > Exported Root & STS certificates. Imported root certificate from Farm B
  • Farm B > Exported Root certificate. Imported Root and STS certificates from Farm A.
  • Farm A > Granted Farm B "Full Control" to the Application Load Balancing Service Application by taking the (Get-SPFarm).Id and granting it permissions via powershell
  • Published my MM service application from Farm A. Taken the URL and pasted into the dialog in Farm B when I try to "connect" Farm B to Farm A's Managed Metadata app. ULS log entry below.
  • Farm B >> Tried running the receive-spserviceapplicationConnectionInfo command pointing to https://farmA:32844/topology/topology.svc (get an 'object reference not set' error)
  • Verified that both farms have an identical clock time

Error from my uls log from when I try to setup the proxy connection on Farm B via Central Admin

An exception occurred when calling SPTopologyWebServiceApplicationProxy.EnumerateSharedServiceApplications on service https://sp2010-wfe1.contoso.com:32844/topology/topology.svc : System.ServiceModel.Security.MessageSecurityException: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. ---> System.ServiceModel.FaultException: An error occurred when processing the security tokens in the message.     --- End of inner exception stack trace ---    Server stack trace:      at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)     at System.ServiceModel.Channels.SecurityChannelFactory`1.Secu... 6b701e6e-ee1d-408e-82e1-1293fa621cba

Any suggestions?

Update: I tried two things, both without success. - Updating to SP1 - Running Wireshark to verify the servers were actually speaking with each other (they are)

2 Answers 2

1

It looks like you mixed up the farms. This is how to do it

  1. On Consuming farm: export root and STS cert
  2. On Publishing farm: export root cert
  3. On Consuming farm: import publishing farm root cert
  4. On Publishing farm: import consuming farm root and STS cert
  5. On Publishing farm: set permissions on topology service using Consuming farm id
  6. On Publishing farm: publish the SA
  7. On Publishing farm: set permissions on the published SA
  8. On Consuming farm: consume the SA

And you don't need any specific certificates - SharePoint has its own certificate store.

2
  • That looks to be exactly what I've done. Note to self: RTFM properly. Will give it a go tonight. Jan 1, 2012 at 14:21
  • Yup. I'd stupidly switched them around. Once I generated the STS cert from the consuming farm and hooked it up to the Provider farm everything worked like a charm. Jan 1, 2012 at 15:30
-1

I would recommend using your existing Certificate Authority or standing one up for this. Each server in the domain will automatically trust certificates issued from the Certificate Authority, which removes one potential problem. You will also have much more control over the certificates that way (revocation, renewing, etc.). Not to mention the fact that you can issue wildcard certs or SAN certs to make your life easier.

Are both farms in the same domain? If not, you'll have to add a trust relationship in Central Administration as well.

1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.