I wrote a Windows service a few years back that processed data from several sources, one of which was a third party SOAP Web Service. It authenticated with this Web Service using a client certificate provided by the third party. This worked fine at the time, and is still working fine on the original machine it was deployed to, but now they are migrating to a new machine where the connection attempt is throwing an exception with the message:
The HTTP request was forbidden with client authentication scheme 'Anonymous'
The same thing is now also occurring on my development machine. This is the code that configures the connection to the web service:
Friend Shared Function GetProperlyConfiguredConnection() As SEMOService.MIWebServiceClient
' Ensure that the settings are valid
ValidateSettings()
Dim destAddress As New System.ServiceModel.EndpointAddress(Url)
' The service uses SOAP 1.1 which is what BasicHttpBinding uses. WSHttpBinding uses SOAP 1.2.
'Dim destBinding As New System.ServiceModel.WSHttpBinding
Dim destBinding As New System.ServiceModel.BasicHttpBinding
With destBinding
.CloseTimeout = New TimeSpan(0, 1, 0)
.OpenTimeout = New TimeSpan(0, 1, 0)
.ReceiveTimeout = New TimeSpan(0, 10, 0)
.SendTimeout = New TimeSpan(0, 1, 0)
.BypassProxyOnLocal = False
.HostNameComparisonMode = ServiceModel.HostNameComparisonMode.StrongWildcard
.MaxBufferPoolSize = 524288
.MaxReceivedMessageSize = 2147483647
.MessageEncoding = ServiceModel.WSMessageEncoding.Text
.TextEncoding = System.Text.Encoding.UTF8
.UseDefaultWebProxy = True
.AllowCookies = False
With .ReaderQuotas
.MaxDepth = 32
.MaxStringContentLength = 2147483647
.MaxArrayLength = 50000000
.MaxBytesPerRead = 4096
.MaxNameTableCharCount = 16384
End With
.Security.Mode = ServiceModel.BasicHttpSecurityMode.Transport
.Security.Transport.ClientCredentialType = ServiceModel.HttpClientCredentialType.Certificate
End With
Dim wcfService As New SEMOService.MIWebServiceClient(destBinding, destAddress)
' Load the certificate from the specified file.
Dim keyData As Byte()
Dim keyFileInfo As New IO.FileInfo(SEMOServiceSettings.KeyFilePath)
Dim keyFileReader As New IO.BinaryReader(New IO.FileStream(SEMOServiceSettings.KeyFilePath, IO.FileMode.Open, IO.FileAccess.Read))
keyData = keyFileReader.ReadBytes(keyFileInfo.Length)
keyFileReader.Close()
Dim cert As New X509Certificates.X509Certificate2
cert = New X509Certificates.X509Certificate2(keyData, SEMOServiceSettings.KeyFilePassword)
wcfService.ClientCredentials.ClientCertificate.Certificate = cert
Return wcfService
End Function
It is not actually a WCF web service, but Visual Studio didn't seem to mind when auto-generating the client code from the WSDL. The client certificate is loaded up from a file rather than from the certificate store. The same certificate file is in use on all the machines, and appears to be loaded up fine when stepping through the code.
I compared the requests being made from the machine that works to one from my dev machine using WireShark, and it appears that the client certificate is not being included in the handshake when it should be:
This is the corresponding packet from a request on the machine that works:
There is much about WCF, SOAP and cryptography that I don't understand, so I am at a bit of a loss as to what could be different about the environments to result in this behaviour, and what needs to change to correct it.
This question seems to be related, but I can't seem to access any RequireClientCertificate property through code, and am not using an app.config to configure the binding.
It is possible to add a callback to the ServicePointManager class for performing custom validation of the server certificate. Does the base client class or the binding perform some validation of the client certificate before sending it to the server? If so, is there a way I can intervene in that process in the same way that I can for the server certificate validation, so that I can see what is going on?
I found the solution, though I'm not sure I understand it fully. The problem was that the client certificate (or perhaps just some of the other certificates in the chain) needed to be present in the Personal certificate store of the user making the request. I logged on as the user that the Windows Service runs as, imported the certificate into its store, and everything is working now.
This suggests that client certificates are validated in some way even if they are loaded from files rather than referenced in the store. This was actually evident in the output of ProcMon, if I'd been paying better attention I would have realised that it was searching the certificate store and coming up with NOT FOUND results.
It would be nice if Microsoft's WCF client code threw an exception if it has a problem with a certificate, rather than just trying to carry on without it. Ah well...
