Couchbase dotnet SDK OSX libcurl error

Howdy all,

I have been trying to use the couchbase-net-client

dotnetcore web app on OSX

  • netcoreapp 1.1
  • CouchbaseNetClient 2.4.2
  • Couchbase server - Version: 4.6.0-3453 Enterprise Edition (build-3453) (in docker container)

Getting the following exception: -

System.PlatformNotSupportedException: The libcurl library in use (7.51.0) and its SSL backend (“SecureTransport”) do not support custom handling of certificates. A libcurl built with OpenSSL is required.

This is sort of covered in the following issue but I have check and am running a far later version (7.51.0 - Nov 2 2016) of libcurl than Jae mentioned in the following Jira ticket NCBC-1296

I am trying to perform FTS and using the following as a guide, but get no results, and when i inspect my bucker.Query results.Exception I get the above message.

I have noted even in v 4.6 the FTS is not fully supported

Important: The FTS feature is a developer preview in Couchbase Server 4.6. As such, the support in the SDK is still uncomitted and the API is subject to change (although no major changes are expected as of this writing).

Has anyone else had this issue?

Should I just implement the REST Api directly instead?


@peter.sawyer -

The issue is not the SDK, its the .NET Core implementation of HttpClient and TLS/SSL on OSX which depends upon the version of libcurl that you have installed on your OS. That being said our goal is to fully support .NET Core on Linux, OSX, and Windows so we very much want a resolution or work-around for this issue. At the moment, the best thing to do is to file a Jira ticket (after creating an account).

  • If you need help creating the Jira ticket, let us know and we will help
  • If you can find a solution or work-around, please post it here or on the ticket
  • Do you need SSL/TLS right now? Can you bypass it for now?

You can take this approach, but you’ll still end up using HttpClient and probably run into the same issue. Additionally, the SDK hides a lot of complexity of the FTS API, load balancing and handles rebalancing and failover and other topology changes that standalone REST API do not handle. For future proofing yourself, your better off sticking with the SDK.




Sorry late response.

Thanks for your prompt reply.

I now have an account in Jira.

With regards to the need for SSL - well no, I set UseSsl to false but it seems that the library still needs to bind.

See example C# for your reference.

public string TestCouchQuery() {

    var config = new ClientConfiguration {
        Servers = new List<Uri> {new Uri("http://localhost:8091/pools")},
        UseSsl = false,
        DefaultOperationLifespan = 1000,
        BucketConfigs = new Dictionary<string, BucketConfiguration> {
            {"default", new BucketConfiguration {
                BucketName = "default",
                UseSsl = false,
                Password = "",
                DefaultOperationLifespan = 2000,
                PoolConfiguration = new PoolConfiguration {
                    MaxSize = 10,
                    MinSize = 5,
                    SendTimeout = 12000

    using (var cluster = new Cluster(config)) {
        IBucket bucket = null;
        try {
            bucket = cluster.OpenBucket();
            SearchQuery searchQuery = new SearchQuery {
                Index = "mdr",
                Query = new MatchQuery("tick"),
                SearchParams = new SearchParams().Limit(10).Timeout(TimeSpan.FromMilliseconds(10000))
            var results = bucket.Query(searchQuery);

            return results.Count().ToString();

        } finally {
            if (bucket != null) {
    return "";


I think this is a problem the .Net Core team is actively working on fixing, see this commit

You might try pulling their beta bits from the .Net Core myget feed and see if that fixes it. Not great for production, but could be a dev workaround and I’m sure it will be released before too long.


Hi @peter.sawyer
Unfortunately dotnet core support for HttpClient is patchy and work arounds changed frequently. The problem here is that dotnet core depends on OpenSSL on some platforms when using HttpClient. Also, even though you are not using SSL, the interop implementation for some platforms still invokes some SSL authentication process which is misleading.

As @btburnett3 mentioned, the dotnet core team are actively working on improving System.Http library compatibility with fixes for non-Windows hosts. The Github issue is specifically aimed at removing the OpenSSL dependency.

What OS are you using to run your netcore app?

@MikeGoldsmith - I am running OSX 10.12.3 (16D32) Sierra