Greg, This is a bit of an educated guess here, but I had a similar problem last week and I ended up having to force a host header value into the IIS binding for the https side of things. The article on how to do that is: https://technet.microsoft.com/en-us/library/cc753195%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
The Stack Overflow question that pointed me in the right direction was: http://stackoverflow.com/questions/3750945/wrong-url-in-wsdl-hyperlink-when-using-wcf-https. The symptom that confirmed it was that if I views the WSDL generated by the WCF service it displayed the internal host name, not the FQDN of the site I needed to browse to. Cheers, Iain On 21 April 2015 at 15:12, Greg Keogh <g...@mira.net> wrote: > I went away to pat the cat and think about it before giving up. I came > back and... > > I removed http binding from the web site in IIS, so it just has a single > https entry. I removed the pairs of config binding and behaviour elements, > so it just has https related items. > > *Now it works!* Some quick experiments confirm that any only this fix > combination seems to work, any extra config elements or IIS bindings cause > stalls or 404s. Also, the <service name="X"> value has to match the > namespace of the service. > > This is great, but ... it means that I can't deploy a single config file > for both http and https. Unless I discover some config trick to support > both bindings my workaround might be to put a question dialog in the MSI > sequence to ask if the install is going to be http(s) and then include the > appropriate <system.serviceModel> element. > > At least the sanity check part is over and we have proof that the service > will run secured. The (stripped down) config looks like the one below. > > *Greg K* > > <system.serviceModel> > <bindings> > <basicHttpBinding> > <binding name="Bind2"> > <security mode="Transport"> > <transport clientCredentialType="None"/> > </security> > </binding> > </basicHttpBinding> > </bindings> > <serviceHostingEnvironment aspNetCompatibilityEnabled="false"/> > <services> > <service behaviorConfiguration="Behave2" > name="RCS.Aggregate.HostApp.Aggregation"> > <endpoint address="" binding="basicHttpBinding" > bindingConfiguration="Bind2" > contract="RCS.Aggregate.HostApp.IAggregationWebService"/> > <endpoint address="mex" binding="mexHttpsBinding" > contract="IMetadataExchange"/> > </service> > </services> > <behaviors> > <serviceBehaviors> > <behavior name="Behave2"> > <serviceMetadata httpsGetEnabled="true"/> > <serviceDebug includeExceptionDetailInFaults="true"/> > </behavior> > </serviceBehaviors> > </behaviors> > </system.serviceModel> > > On 21 April 2015 at 14:53, noonie <neale.n...@gmail.com> wrote: > >> You don't have another web site that's bound to port 443 do you? >> >> -- >> noonie >> On 21/04/2015 2:42 PM, "Greg Keogh" <g...@mira.net> wrote: >> >>> Can you put a static resource such as an image or text file in the >>>> folder to ensure you can access that static resource via https. >>>> >>> >>> Yes, I can see https://www.orthogonal.net.au/rubyservice/setup.bmp >>> okay, the svc file (Aggregation.svc) in the same location gives the 404. >>> I'm still researching, but I might wait until tomorrow morning and ask my >>> cat -- *Greg K* >>> >> >
