Rampid Byter

Added SSL recently to our production WCF service site. The big change happened when trying to setup a customer feed to begin testing implementations against the fixed service location. After setting the site to require SSL a particular friendly yellow-screen-of-death appeared with the following message “The HttpGetEnabled property of ServiceMetadataBehavior is set to true and the HttpGetUrl property is a relative address, but there is no http base address.  Either supply an http base address or set HttpGetUrl to an absolute address.”

The fix is to change the httpGetEnabled=”true” to httpsGetEnabled=”true” under serviceMetadata tag for the defined service behavior settings. A simple little s character cost an hour of time in configuration to find. There was another one similar when changing the IMetadataExchange endpoint to use mexHttpsBinding instead of mexHttpBinding. That was another topic all together but very related as far as the fix. Below you’ll find a snippet of the configuration section with https changes.

   1:          <behaviors>

   2:              <serviceBehaviors>

   3:                  <behavior name="Services.ServiceBehavior">

   4:                      <serviceCredentials>

   5:                          <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="Services.Validators.UserValidator, Services"/>

   6:                      </serviceCredentials>

   7:                      <serviceMetadata httpsGetEnabled="true" />

   8:                      <serviceDebug includeExceptionDetailInFaults="false" />

   9:                  </behavior>

  10:              </serviceBehaviors>

  11:          </behaviors>

WCF

Ok, I’m new to Windows Communication Foundation (WCF), and I admit that upfront. I ran into the 403.1 error while trying to host my first WCF service. I spend time configuring the .Net framework associated to the application pool with associated identity user account permissions. Not to mention Google/Binging for help on why I kept getting the error page about access denied.

I came across a few blogs mentioning the 403.1 error and WCF that did not help me. Essentially most blog references just make sure that you’re actually trying to access the file in the folder hierarchy where the actual file is located. If that isn’t the first thing you check I don’t think you should be configuring IIS service hosting.

I did find my particular 403.1 problem. The application pool was using NETWORK SERVICE to secure the service, which I had added with full permission to try to solve the access permission. That didn’t work of course, and so I then tried adding the ASPNET user with read/write permissions to the service virtual folder in IIS 6. Sure enough that fixed my problem. No more 403.1 error page!

Again, try adding either NETWORK SERVICE and very least ASPNET accounts with read/write permissions to your service folder if you’re getting the 403.1 error. Double check the application pool identity to make sure Iit has permission as that could potentially be a cause. Once the service starts working please do audit the permissions according to your needs. If that fails to help try user impersonation in WCF, or I found the random solution possibilities of the Microsoft community forum somewhat helpful in pointing my way to the solution.

WCF