Wcf: Basic httpsbinding client certificate fails on *nix but works on windows

[Priya91]

_From @mwdavisii on July 19, 2016 12:58_

This is a cross post from dotnet/KestrelHttpServer and WCF. I've closed that issue as it is not Kestrel related, but I apologize for the cross-posting, I'm still learning about the different repositories and what functions are where.

I have some functionality that is working on windows, but fails on all of the unix droplets I've spun up. I'm seeing one type of failure message on ubuntu 14.04 and debian 8.5 and another type on fedora 23 and centos 7 when using BasicHttpsbinding and the connection factory. I've tried using the svcutil to generate the interface and I've also used the new WCF Connected Services utility and I've even crafted the entire message by hand and used SendAsync and PostAsync. All scenarios exhibit the same behavior.

Here's the code:
```c#
private string invokeSsoSoapRequest(string xmlRequest)
{
ChannelFactory factory = null;
SingleSignOnSoap serviceProxy = null;
var binding = new BasicHttpsBinding();
binding.Security.Mode = BasicHttpsSecurityMode.Transport;
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;

    var baseAddress = new Uri(mySettings.ClientUrl);
    var endpointAddress = new EndpointAddress(baseAddress);

    X509Certificate2Collection collection = new X509Certificate2Collection();

    if (RuntimeEnvironment.OperatingSystemPlatform == Platform.Windows)
    {
        //windows file location
        collection.Import(mySettings.ClientPrivateKeyWindowsPath, mySettings.ClientPfxPass, X509KeyStorageFlags.PersistKeySet);
    }else
    {
        collection.Import(mySettings.ClientPrivateKeyUnixPath, mySettings.ClientPfxPass, X509KeyStorageFlags.PersistKeySet);
    }

    //parse pfx for client auth key
    factory = new ChannelFactory<SingleSignOnSoap>(binding, new EndpointAddress(baseAddress));
    foreach (X509Certificate2 cert in collection)
    {
        if (cert.HasPrivateKey)
        {
            factory.Credentials.ClientCertificate.Certificate = cert;
        }
    }
    serviceProxy = factory.CreateChannel();
    RequestTicketRequest request = new RequestTicketRequest();
    RequestTicketRequestBody body = new RequestTicketRequestBody();
    request.Body = body;
    request.Body.sRequestXML = xmlRequest;
    return serviceProxy.RequestTicket(request).Body.RequestTicketResult;
}

}
```

`
Here are the errors I'm getting on Ubuntu and Debian:

TimeoutException: The HTTP request to 'https://services.**SingleSignOn.asmx' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout.

The above dotnet error claims the service timed out while waiting for a response (00:01:00), but a tshark trace shows the SOAP response negotiation failed when the client sent [RST, ACK] back the the remote webservice. See image below. The same trace in windows environment shows no errors and the transaction works and as you can see a few lines above, the server hello, certificate, and key exchanges appear to be successful, so I don't think I'm dealing with a cert issue.

I've also tried this in docker just to rule out any host config issues with the following docker config and see the same error:

FROM microsoft/dotnet:1.0.0-preview2-sdk
RUN mkdir -p /dotnetapp
WORKDIR /dotnetapp
EXPOSE 5000
COPY . /dotnetapp
RUN dotnet restore
ENTRYPOINT ["dotnet", "run"]`

I've tried this on Fedora and Centos, but get a different error related to the curl version that ships with those distros. I'm not entirely sure how to fix it, but I suspect I'd have the same issue if I got past it.

Here is the error I received on Fedora and Centos:

System.PlatformNotSupportedException: The libcurl library in use (7.43.0) and its SSL backend ("NSS/3.24 Basic ECC") do not support custom handling of certificates. A libcurl built with OpenSSL is required.

*As a note, I compiled 7.50 curl against openssl and still received the above error. I'm a little bit of a linux noob, so I'm not sure if there's a way to force dotnet core to use the 7.5 installation, but as of now, dotnet core is still using 7.4.3.

Here is my project.json
{ "dependencies": { "Microsoft.NETCore.App": { "version": "1.0.0", "type": "platform" }, "Microsoft.AspNetCore.Mvc": "1.0.0", "Microsoft.AspNetCore.Server.Kestrel": "1.0.0", "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0", "Microsoft.Extensions.Configuration.FileExtensions": "1.0.0", "Microsoft.Extensions.Configuration.Json": "1.0.0", "Microsoft.Extensions.Logging": "1.0.0", "Microsoft.Extensions.Logging.Console": "1.0.0", "Microsoft.Extensions.Logging.Debug": "1.0.0", "Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0", "System.ServiceModel.Http": "4.1.0", "System.Xml.XmlSerializer": "4.0.11", "Microsoft.Extensions.Options": "1.0.0", "System.Runtime.Extensions": "4.1.0", "System.Text.Encoding": "4.0.11", "System.Xml.XmlDocument": "4.0.1", "System.Xml.XDocument": "4.0.11", "System.Security.Cryptography.X509Certificates": "4.1.0", "System.Security.Cryptography.Csp": "4.0.0", "system.xml.xpath.xmldocument": "4.0.0", "JsonWebTokens": "1.2.0", "Microsoft.AspNetCore.Diagnostics": "1.0.0", "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0" }, "tools": { }, "frameworks": { "netcoreapp1.0": { "imports": [ "dotnet5.6" ] } }, "buildOptions": { "emitEntryPoint": true, "preserveCompilationContext": true, "debugType": "portable" }, "runtimeOptions": { "configProperties": { "System.GC.Server": true } }, "publishOptions": { "include": [ "wwwroot", "Views", "Areas/**/Views", "appsettings.json", "web.config", "Dockerfile" ] }, "scripts": { "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ] } }

As I said on my other post, I would appreciate any help and know that it's more than plausible I've done something wrong here. This is the only piece of this API stack that we haven't been able to port.

Lastly, if I can provide any other information, please let me know!
Thank you!

_Copied from original issue: dotnet/corefx#10146_

[Priya91]

_From @ericeil on September 8, 2016 18:32_

@mwdavisii, I'm sorry for the slow response to this issue. Thank you for reporting it! Before I dig in further, have you made any progress on this from your end since reporting this?

[Priya91]

_From @mwdavisii on September 8, 2016 18:56_

No worries! No, I haven't been able to get past it. I ended up writing a class wrapper to call a bash script I wrote that calls curl directly. It feels nasty, but I commented the function heavily and added a link to this issue with the hope of making it work the right way one day.

```c#
if (RuntimeEnvironment.OperatingSystemPlatform == Platform.Windows)
{
//Invoke SSO Service
response = invokeSSO(xmlRequest);
}
else
{

            //open up RunShell to execute bash script
            ShellWrapper runShell = new ShellWrapper(this.mySettings, this.myLogger, this.myHostingEnv);

            response = runShell.invokeViaCurlCommandLine(customerIdentification.clientID, employeeID);

        }

```

I suspect it's not a very common problem as we're consuming a vendor's old dotnet soap service (looks like maybe 1.1), which also appears to be poorly defined and designed - the input parameters expect xml as string (CDATA) and the WSDL points to http when the service lives at https, and all of the responses are CDATA XML as well.

[Priya91]

_From @karelz on March 2, 2017 19:19_

@Priya91 can you please triage it?

[joeyaiello]

Just want to throw a +1 in here that this is blocking a number of customers using VMware's PowerCLI with PowerShell on Linux (specifically CentOS, openSUSE, or any distros where libcurl is not compiled with libssl).

[karelz]

@Priya91 what is the gist of the problem? Is it a bug in WCF? Or outcome of older libcurl version on the OS?

[karelz]

cc @shmao @zhenlan as it seems to be impactful

[Priya91]

@karelz I haven't investigated this issue, the apis in use are not in .NET Core, these are specific to WCF.

[ryangurazov]

Hi, do we have a most recent status on this issue?
As it is been mentioned above w/o this solution in place Centos and openSUSE are both cannot be used with VMware PowerCLI.

[zhenlan]

@mconnew can you please look into this?

[mconnew]

On unix, HttpClient uses libcurl for communication. libcurl uses openssl for the certificate handling. My understanding is if you give HttpClient an ephemeral certificate which isn't in the local certificate store then libcurl is unable to use it. If you use X509Store to add it to your store, this places it in a special .net folder in your home directory and libcurl still won't find it. You need to install the client cert in your local machine certificate store before HttpClient/libcurl will use it. This is all from memory from over a year ago so @karelz will need to confirm this is still the behavior of HttpClient.

[mconnew]

Closing issue in WCF repo and reopening dotnet/corefx#10146