Hello all,
I've written an WCF-based restful web service as a Windows service and I am accessing it via raw HttpWebRequest from a console application. It works great when I set everything up for plain http. But now, I'm trying to set it up for SSL access using the ASP.NET role provider. Now when it executes request.GetResponse() and it hangs and eventually times out.
I am using "https://localhost:9220" across the board, client and server, and the CN of my certificate is "localhost". It is signed by a CA certificate I generated that is installed in my trusted root certificates. I am using transport security and I have supplied the following commands, so I think my story is pretty good as far as the transport SSL certificate.
netsh http add urlacl url=http://+:9220/ user=****/**** (**** suppressed)
netsh http add sslcert ipport=0.0.0.0:9220 certhash=thehashfromthecertificate appid={uuid-that-i-made-up}
On to the credentials - Here is the service model from my config file:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="SecureBehavior">
<serviceAuthorization principalPermissionMode="UseAspNetRoles"/>
<serviceCredentials>
<userNameAuthentication
userNamePasswordValidationMode="MembershipProvider"/>
<serviceCertificate findValue="localhost" storeLocation="LocalMachine"
storeName="My" x509FindType="FindBySubjectName"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="webHttp">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
<bindings>
<webHttpBinding>
<binding name="webHttp" maxBufferPoolSize="1500000"
maxReceivedMessageSize="1500000" maxBufferSize="1500000">
<security mode="Transport">
<transport clientCredentialType="Basic"/>
</security>
</binding>
</webHttpBinding>
</bindings>
<services>
<service name="ProxyNetworks.Appliance.Engine.TelephonyRecording"
behaviorConfiguration="SecureBehavior" >
<endpoint binding="webHttpBinding"
contract="ProxyNetworks.Appliance.Engine.ITelephonyRecording"
bindingConfiguration="webHttp" behaviorConfiguration="webHttp"/>
</service>
</services>
<diagnostics>
<messageLogging logEntireMessage="true" logMalformedMessages="true"
logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true"
maxMessagesToLog="3000" maxSizeOfMessageToLog="10000" />
</diagnostics>
</system.serviceModel>
As you can see, I am using the serviceAuthorization and userNameAuthentication to hook to the System.Web.Security stuff, which I have also configured in my config file with the connection string that I am using successfully from my web application and from several test applications.
I can think of several places where this could trip up. It could be failing to hook up to the SSL certificate. It could be failing somewhere in the middle of processing the user credentials. It could be failing to get to the service altogether. I've got web service logging turned on for System.ServiceModel and System.IdentityModel. Because this is all done with localhost, Wireshark isn't even aware that there's anything going on. I'm not sure what else will give me insight. I would prefer to see the mechanism of failure and address it rather than to shoot in the dark until I slip in the blood. What would I use to watch what is going on?
UPDATE: When debugging your toaster, first examine where the power cord attaches to the wall. I had http in the client command line rather than https. I must not have changed it back the last time I was switching back and forth.
OK, so now I am actually able to see where it fails next. It would appear that the service is using Windows credentials rather than the ASP.NET Membership stuff, despite my entries in the project's app.config. Is this because the SSL handshaking is occurring in the transport rather than in the WCF layer? Is there any way to redirect it? Do I need to do custom credentials and then wire in the ASP.NET stuff behind there?
Ralph