Client certificates can be a real pain to use for service communication, even though they sound simple enough. Part of the problem is just the very confusing names of the WCF configuration (behaviours, configurations, transports, messages, bindings, mex, blah, blah, blah) and the other is that when they don't work, it is not easy to see why.

I was trying to use SvcUtil.exe to download the wsdl for a couple of service endpoints. In my case, fortunately, I had already used this successfully, so I knew it should work. I had copied the original project and was attempting to download the new wsdl from a staged service instead of the live one but surely, all I needed to do was to change the URL passed to svcutil.exe? Nope. Didn't work.

Error: Cannot obtain Metadata from https:.... 
Metadata contains a reference that cannot be resolved:.... 
The remote server returned an error: (404) 
The remote server returned an error: (403) Forbidden.

That kind of thing.
I immediately suspected that the client certificate was the problem but why does it work on my other project? Same config, same Client Certificate, same web service (but different URL).

Theoretically, you can specify the client certificate credentials in a configuration file that SvcUtil.exe uses but this didn't work at all. I copied the config from my main project's web.config but got the same error.

I then stumbled onto something I had forgotten but which makes it all easier. I had used the Windows Credential Manager to add a certificate-based authentication link between my machine and the target URL of the web service. This is why the original project was working since the certificate was served automatically. This was also why the new one didn't - because there was no entry.

I added an entry for the test URL, linked it to the correct client cert and away we went....SvcUtil.exe uses the same mechanism to collect its client certificates.

No idea why the configuration option didn't work though.