Can this be something besides a cert mismatch?

Question

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 nor am I missing the private key.
 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.

Thanks!

Answer 1

It could be permission issue on the hosting environment machine key.

Please see this post ... though this is more configuring certificates on XP and IIS Express but may give you some insight.

---

Tanvir Huda Application Architect/Consultant http://thetechnocrate.wordpress.com/

Answer 2

It could be permission issue on the hosting environment machine key.

Please see this post ... though this is more configuring certificates on XP and IIS Express but may give you some insight.

---

Tanvir Huda Application Architect/Consultant http://thetechnocrate.wordpress.com/

I don't see how this is possible. These are instances in Azure and they always embed the machinekey into your web.config files behind-the-scenes for you when you have your server provisioned. This way, the machine key is simply pulled from your config file.

The servers' web.config files: <configuration><configSections /><system.web /><machineKey HERE />

Answer 3

Hi,

Shouldn't the service's configure be:

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

http://msdn.microsoft.com/en-us/library/ms731340(v=vs.100)

Also, try set the CertificateValidationMode property to either PeerTrust or PeerOrChainTrust to see if it is chain trust issue.

http://msdn.microsoft.com/en-us/library/aa347703(v=vs.100)

Working with Certificates

http://msdn.microsoft.com/en-us/library/ms731899

Answer 4

Hi,

Shouldn't the service's configure be:

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

http://msdn.microsoft.com/en-us/library/ms731340(v=vs.100)

Also, try set the CertificateValidationMode property to either PeerTrust or PeerOrChainTrust to see if it is chain trust issue.

http://msdn.microsoft.com/en-us/library/aa347703(v=vs.100)

Working with Certificates

http://msdn.microsoft.com/en-us/library/ms731899

What you suggested for the serviceCertificate is invalid - I get dev-time errors with that. The way I have it, it was working perfectly with just Message security before. See the "serviceCertificate Element" section of this MSDN doc - it agrees with my configuration markup.

As for cert trust, this is a fully-legit cert that we purchased from a fully-trusted commercial CA. This isn't an internally-generated cert. There isn't anything wrong with the chain trust in any way. However, just in case I'm misunderstanding this, I tried this with no change in behavior.

Answer 5

After a lot of struggling, found out the problem. Apparently our ADFS configuration has been setup incorrectly for 2 years, just in a way that doesn't affect us. Updating it to be proper made this problem go away. The side-effect of this misconfiguration was that the tokens were being signed with the incorrect cert (however that might happen, I don't know). The misconfiguration was this:

Internal ADFS Server and Federation Service Name: myadfs.mydomain.local
External ADFS Proxy Server: sts.mydomain.com

This right here is enough to point out the misconfiguration if you know about this rarely-mentioned requirement. The federation Service Name, the DNS for the internal ADFS Server, and the DNS for the External ADFS Proxy Server must all be the same. In my case, all of these things must be (and resolve to) sts.mydomain.com. So I had to reconfigure my entire ADFS architecture and my internal DNS so everything pointed to sts.mydomain.com.

In ADFS, you can right-click on a node on the left side and say, "Edit Federation Properties..." (or something like that) and change the Federation Service Name to be the same as your external DNS. Additionally, you must update your entire internal DNS to override the external DNS for sts.mydomain.com so that it resolves to your internal ADFS server instead of your external DNS (i.e. the proxy). Lastly, you have to go fix your code in any and all applications that interact with ADFS.

Absolutely stupid way of doing this (i.e. architecting everything around your proxy) but that was my problem/solution after working with several people at Microsoft on this.