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

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:

    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

[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).

[mconnew]

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