CODEWITHSUNDEEP
c#wcf.net-4.0azure
Jaxidian
Jaxidian

Reputation: 13511

WCF in Azure claims I have a cert mismatch but I don't think I do

Why am I getting this error and what exactly does it mean? Is there something else this could be besides a mismatched cert setup?

I have a locally-running Unit Test that hits an ADFS Proxy at our data center for Active Federation and then hits our WCF web service running in Azure (web role). The client errors out with a MessageSecurityException. So looking at the server's service logs, it logs the exception:

Cannot resolve KeyInfo for decryption: KeyInfo 'SecurityKeyIdentifier
    (
    IsReadOnly = False,
    Count = 1,
    Clause[0] = EncryptedKeyIdentifierClause(EncryptedKey = abcdefg123456==, Method 'http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p')
    )
', available tokens 'System.ServiceModel.Security.AggregateTokenResolver'.

EVERYTHING I find online about this says that I have a certificate mismatch between the client and server. But I've double-, triple-, and quadruple-checked these cert references and they're identical. The client's (local unit test) endpoint:

  <endpoint address="https://mydomain.com/TestService.svc"
            binding="customBinding"
            bindingConfiguration="WS2007FederationHttpBinding_ISayHelloService"
            contract="ActiveFederationHelpers.Tests.ISayHelloService"
            name="WS2007FederationHttpBinding_ISayHelloService">
    <identity>
      <certificateReference findValue="D4ECD7FF6A551FAA040BA0B62B77B8EA0F11CD16"
                            storeLocation="LocalMachine"
                            storeName="My"
                            x509FindType="FindByThumbprint" />
    </identity>
  </endpoint>

My server's service config (I RDP'd into an Azure instance to pull from there to confirm it's really what I think it is):

<serviceCertificate>
    <certificateReference findValue="D4ECD7FF6A551FAA040BA0B62B77B8EA0F11CD16" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
</serviceCertificate>

I've confirmed that these certs are installed both on my local machine (unit test) and the Azure server (web service server). And I've even confirmed that the thumbprint are what's in my config. I have this all running successfully in a local environment. The ONLY differences are certs, URIs, and the introduction of Azure.

A few other things I've double-checked:

  1. No, I didn't copy/paste the thumbprint with the unicode chars in there. I'm reusing my SSL cert for my services and SSL works perfectly so it's not a typo in the thumbprint.
  2. There is no older or alternative version of this cert that might be confusing me. Like I said, I've been inspecting the cert's thumbprints (in MMC -> Certs) every time I ensure it's installed.

Upvotes: 0

Views: 279

Answers (1)

Jaxidian
Jaxidian

Reputation: 13511

Ultimately, ADFS was misconfigured and somehow this was the resulting error. The misconfiguration was due to my Federation Service Name not being a hostname that resolved to the ADFS Proxy (just the ADFS server itself). Rearchitecting our ADFS setup around our public Proxy's hostname resolved these problems for us.

I suspect the reason this wasn't an issue outside of Azure was because the Federation Service Name resolved to the internal server and not the external proxy and Azure only had access to the external proxy.

Either way, moral of the story (that nearly nobody seems to talk about) is that your Federation Service Name must be a public URI if you expect to ever use a Proxy with it, and that Proxy must resolve to that public URI!

Upvotes: 0

Related Questions