C SDK 3.3.1 TLS authentification doesn't work with the couchbase server enterprise 7.1.3 image

Hello,

I’m currently in the process of troubleshooting a few issues with a TLS connection to the blank ([docker/enterprise/couchbase-server/7.1.3 at master · couchbase/docker · GitHub](https://Couchbase Enterprise Server 7.1.3 Docker image). Note that I’ve checked that ports the container is listening to all relevant ports (18091, 11207, 8091, …).

I’m setting up the cluster, data buckets and application access users via the REST API using a small python script.
Another thing the script does it loads the trusted Root CA from the running server in order to authenticate with it (see further down). I want to get this running before I go through the hustle of creating the next steps for a ‘proper’ certifacate setup.

I followed the C SDK Documentation to write up a small API. The C++ API basically creates the connection string like this:

std::string connStr  = "couchbases://" + host + "/" + bucket + "?certpath="+ certificateFile + "&detailed_errcodes=1"

Afterwards the lcb_CREATEOPTS* is filled like this:

// assuming `lcb_createopts_create` succeeds of course...
lcb_createopts_connstr( options, connStr.c_str(), connStre.length() );
lcb_createopts_bucket( options, bucket.c_str(), bucket.length() );
lcb_createopts_credentials( options, bucketUser.c_str(), bucketUser.length(), authPass.c_str(), authPass.length() );

The lcb_INSTANCE* is instantiated like this;

lcb_INSTANCE *context = nullptr;
lcb_STATUS status = lcb_create( &context, options );
lcb_createopts_destroy( options );
if ( status != LCB_SUCCESS )
{
   // log...
}

lcb_STATUS connectStatus = lcb_connect( context );
if ( connectStatus == LCB_SUCCESS )
  connectStatus = lcb_wait( context, LCB_WAIT_DEFAULT );

if ( connectStatus == LCB_SUCCESS )
{
   lcb_STATUS bootstrapStatus = lcb_get_bootstrap_status( context );
   if ( bootstrapStatus != LCB_SUCCESS )
   {
      // log... 
   }
}
else
{
   // log...
}

The log from the wait statement is libcouchbase error: LCB_ERR_SSL_CANTVERIFY (1003).
Which IIRC tells me that the SSL verification can’t be done on the server. If I turn the verification of on the with the connection string by appending ``&ssl=no_verify` it ‘works’.

Running the sdb-doctor on said docker container returns:

|====================================================================|
|          ___ ___  _  __   ___   ___   ___ _____ ___  ___           |
|         / __|   \| |/ /__|   \ / _ \ / __|_   _/ _ \| _ \          |
|         \__ \ |) | ' <___| |) | (_) | (__  | || (_) |   /          |
|         |___/___/|_|\_\  |___/ \___/ \___| |_| \___/|_|_\          |
|                                                                    |
|====================================================================|

Note: Diagnostics can only provide accurate results when your cluster
 is in a stable state.  Active rebalancing and other cluster configuration
 changes can cause the output of the doctor to be inconsistent or in the
 worst cases, completely incorrect.

09:48:11.195 INFO ▶ Parsing connection string `couchbases://127.0.0.1/bucket`
09:48:11.195 INFO ▶ Connection string specifies to use secured connections
09:48:11.195 INFO ▶ Connection string identifies the following CCCP endpoints:
09:48:11.195 INFO ▶   1. 127.0.0.1:11207
09:48:11.195 INFO ▶ Connection string identifies the following HTTP endpoints:
09:48:11.195 INFO ▶   1. 127.0.0.1:18091
09:48:11.195 INFO ▶ Connection string specifies bucket `bucket`
09:48:11.195 WARN ▶ Your connection string specifies only a single host.  You should consider adding additional static nodes from your cluster to this list to improve your applications fault-tolerance
09:48:11.195 INFO ▶ Performing DNS lookup for host `127.0.0.1`
09:48:11.195 INFO ▶ Attempting to connect to cluster via CCCP
09:48:11.195 INFO ▶ Attempting to fetch config via cccp from `127.0.0.1:11207`
09:48:11.196 ERRO ▶ Failed to fetch configuration via cccp from `127.0.0.1:11207` (error: x509: certificate signed by unknown authority)
09:48:11.196 INFO ▶ Attempting to connect to cluster via HTTP (Terse)
09:48:11.196 INFO ▶ Attempting to fetch terse config via http from `127.0.0.1:18091`
09:48:11.198 ERRO ▶ Failed to fetch terse configuration via http from `127.0.0.1:18091` (error: Get "http://127.0.0.1:18091/pools/default/b/bucket": net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x03\x00\x02\x02")
09:48:11.198 INFO ▶ Attempting to connect to cluster via HTTP (Full)
09:48:11.198 INFO ▶ Failed to connect via HTTP (Full), as it is not yet supported by the doctor
09:48:11.198 INFO ▶ Selected the following network type: 
09:48:11.198 ERRO ▶ All endpoints specified by your connection string were unreachable, further cluster diagnostics are not possible
09:48:11.198 INFO ▶ Diagnostics completed

Summary:
[WARN] Your connection string specifies only a single host.  You should consider adding additional static nodes from your cluster to this list to improve your applications fault-tolerance
[ERRO] Failed to fetch configuration via cccp from `127.0.0.1:11207` (error: x509: certificate signed by unknown authority)
[ERRO] Failed to fetch terse configuration via http from `127.0.0.1:18091` (error: Get "http://127.0.0.1:18091/pools/default/b/bucket": net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x03\x00\x02\x02")
[ERRO] All endpoints specified by your connection string were unreachable, further cluster diagnostics are not possible

Found multiple issues, see listing above.

→ Which means that the container can’t verify its own Root CA? I.e. its own generated certificate isn’t trusted on the container itself?

I don’t really know how to continue from here on. Should I troubleshoot the docker container in order to get the SSL verification working? I checked that the certificates are in the /etc/ssl/certs/ folder etc. but that didn’t change something or I missed a step somewhere of course.

In addition I followed the steps from manage server certificates (i.e. before automating it) but with no luck.

From my point of the ‘default’ container should work with my above mentioned approach or am I missing something? I’d appreciate any kind of feedback.

@avsej ?

You could use openssl against your server to verify independently of the sdk.

SDK Doctor doesn’t use the SDK so that’s a good indicator there is an issue with the certificate.

You may also benefit from using a later SDK version.

First of all thank you for your suggestions!

Here is the output for openssl s_client -CApath <..> -connect 127.0.0.1:18091

CONNECTED(00000003)
---
Certificate chain
 0 s:CN = Couchbase Server Node (127.0.0.1)
   i:CN = Couchbase Server 236d0f2c
 1 s:CN = Couchbase Server 236d0f2c
   i:CN = Couchbase Server 236d0f2c
---
Server certificate
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
subject=CN = Couchbase Server Node (127.0.0.1)

issuer=CN = Couchbase Server 236d0f2c

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2195 bytes and written 363 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self signed certificate in certificate chain)
---

Which results in the same verification error IIRC. Note that the docker container is running locally, for now. I ommited the body of the certificate, just to be on the safe side.

So my take from this is that indeed the issue for know lies in the setup of the default setup of the docker container? I know it’s not necessary recommended to use the default certificate.
However IIRC the uploading of new certificates should also be be processed on the container. Of course I don’t know the details of the implementation, but if the default certificate is uploaded similarly to ‘correct’ ones the issue could persist.

As you’ve mentioned an update to the C SDK could be an idea to try, but seing that the issue certainly lies in the certificate itself I don’t think necessary just yet. But I’ve seem some changelog entries regarding some SSL cases on your side of things.
The last one that fixed things regarding these things in C SDK 3.3.5, would you recommend it?

I tried this myself and did not have an issue. Note that the certificate will be different every time you run docker, so server.pem needs to be recreated every time.

 docker run -d --name db -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 couchbase

now go to http://localhost:8091/ui/index.html
It shows Enterprise Edition 7.1.4 build 3601
Select "Setup New Cluster"
Clustername: MyCluster
Username:  leave as Administrator
Password: password
Next Accept Terms: [Accept]
Finish With Defaults
Buckets - "You have no buckets, create a [sample bucket]"
check "travel-sample", [Load Samples]
Security
[Certificates]
Copy the first certificate, create server.pem, past certificate into server.pem.
Copy the second certificate, paste into server.pem below the first one.
Then run sdk-docctor
 ./sdk-doctor-macos diagnose --tls-ca ../server.pem -u Administrator -p password couchbases://127.0.0.1/travel-sample
|====================================================================|
|          ___ ___  _  __   ___   ___   ___ _____ ___  ___           |
|         / __|   \| |/ /__|   \ / _ \ / __|_   _/ _ \| _ \          |
|         \__ \ |) | ' <___| |) | (_) | (__  | || (_) |   /          |
|         |___/___/|_|\_\  |___/ \___/ \___| |_| \___/|_|_\          |
|                                                                    |
|====================================================================|

Note: Diagnostics can only provide accurate results when your cluster
 is in a stable state.  Active rebalancing and other cluster configuration
 changes can cause the output of the doctor to be inconsistent or in the
 worst cases, completely incorrect.

12:43:02.001 INFO ▶ Parsing connection string `couchbases://127.0.0.1/travel-sample`
12:43:02.001 INFO ▶ Connection string specifies to use secured connections
12:43:02.001 INFO ▶ Connection string identifies the following CCCP endpoints:
12:43:02.001 INFO ▶   1. 127.0.0.1:11207
12:43:02.001 INFO ▶ Connection string identifies the following HTTP endpoints:
12:43:02.001 INFO ▶   1. 127.0.0.1:18091
12:43:02.001 INFO ▶ Connection string specifies bucket `travel-sample`
12:43:02.001 WARN ▶ Your connection string specifies only a single host.  You should consider adding additional static nodes from your cluster to this list to improve your applications fault-tolerance
12:43:02.001 INFO ▶ Performing DNS lookup for host `127.0.0.1`
12:43:02.001 INFO ▶ Attempting to connect to cluster via CCCP
12:43:02.001 INFO ▶ Attempting to fetch config via cccp from `127.0.0.1:11207`
12:43:02.024 INFO ▶ Selected the following network type: default
12:43:02.024 INFO ▶ Identified the following nodes:
12:43:02.024 INFO ▶   [0] 127.0.0.1
12:43:02.024 INFO ▶                  ftsGRPC:  9130,           ftsGRPCSSL: 19130,   indexStreamCatchup:  9104
12:43:02.024 INFO ▶                  capiSSL: 18092,           backupGRPC:  9124,                kvSSL: 11207
12:43:02.024 INFO ▶                backupAPI:  8097,              cbasSSL: 18095,    eventingAdminPort:  8096
12:43:02.024 INFO ▶            eventingDebug:  9140,               ftsSSL: 18094,                 cbas:  8095
12:43:02.024 INFO ▶                     n1ql:  8093,       backupAPIHTTPS: 18097,                  fts:  8094
12:43:02.024 INFO ▶              eventingSSL: 18096,            indexHttp:  9102,           indexHttps: 19102
12:43:02.024 INFO ▶          indexStreamInit:  9103,     indexStreamMaint:  9105,                   kv: 11210
12:43:02.024 INFO ▶                projector:  9999,                 capi:  8092,            indexScan:  9101
12:43:02.024 INFO ▶                     mgmt:  8091,              mgmtSSL: 18091,              n1qlSSL: 18093
12:43:02.024 INFO ▶               indexAdmin:  9100
12:43:02.024 INFO ▶ Fetching config from `https://127.0.0.1:18091`
12:43:02.060 INFO ▶ Received cluster configuration, nodes list:
[
  {
    "addressFamily": "inet",
    "addressFamilyOnly": false,
    "clusterCompatibility": 458753,
    "clusterMembership": "active",
    "configuredHostname": "127.0.0.1:8091",
    "couchApiBase": "http://172.17.0.2:8092/",
    "couchApiBaseHTTPS": "https://172.17.0.2:18092/",
    "cpuCount": 6,
    "externalListeners": [
      {
        "afamily": "inet",
        "nodeEncryption": false
      }
    ],
    "hostname": "172.17.0.2:8091",
    "interestingStats": {
      "cmd_get": 0,
      "couch_docs_actual_disk_size": 67018367,
      "couch_docs_data_size": 47971386,
      "couch_spatial_data_size": 0,
      "couch_spatial_disk_size": 0,
      "couch_views_actual_disk_size": 0,
      "couch_views_data_size": 0,
      "curr_items": 63288,
      "curr_items_tot": 63288,
      "ep_bg_fetched": 0,
      "get_hits": 0,
      "index_data_size": 483480,
      "index_disk_size": 1278876,
      "mem_used": 106204608,
      "ops": 2340.5,
      "vb_active_num_non_resident": 0,
      "vb_replica_curr_items": 0
    },
    "mcdMemoryAllocated": 6367,
    "mcdMemoryReserved": 6367,
    "memoryFree": 5718966272,
    "memoryTotal": 8346509312,
    "nodeEncryption": false,
    "nodeHash": 116235652,
    "nodeUUID": "54c27075ca02a15d6c07195faa7f018c",
    "os": "x86_64-pc-linux-gnu",
    "otpNode": "ns_1@127.0.0.1",
    "ports": {
      "direct": 11210,
      "distTCP": 21100,
      "distTLS": 21150,
      "httpsCAPI": 18092,
      "httpsMgmt": 18091
    },
    "recoveryType": "none",
    "serverGroup": "Group 1",
    "services": [
      "backup",
      "cbas",
      "eventing",
      "fts",
      "index",
      "kv",
      "n1ql"
    ],
    "status": "healthy",
    "systemStats": {
      "allocstall": 0,
      "cpu_cores_available": 6,
      "cpu_stolen_rate": 0,
      "cpu_utilization_rate": 94.93970723079448,
      "mem_free": 5718966272,
      "mem_limit": 8346509312,
      "mem_total": 8346509312,
      "swap_total": 1073737728,
      "swap_used": 0
    },
    "thisNode": true,
    "uptime": "766",
    "version": "7.1.4-3601-enterprise"
  }
]
12:43:02.066 INFO ▶ Successfully connected to Key Value service at `127.0.0.1:11207`
12:43:02.075 INFO ▶ Successfully connected to Management service at `127.0.0.1:18091`
12:43:02.175 INFO ▶ Successfully connected to Views service at `127.0.0.1:18092`
12:43:02.180 INFO ▶ Successfully connected to Query service at `127.0.0.1:18093`
12:43:02.184 INFO ▶ Successfully connected to Search service at `127.0.0.1:18094`
12:43:02.281 INFO ▶ Successfully connected to Analytics service at `127.0.0.1:18095`
12:43:02.295 INFO ▶ Memd Nop Pinged `127.0.0.1:11207` 10 times, 0 errors, 0ms min, 0ms max, 0ms mean
12:43:02.295 INFO ▶ Diagnostics completed

Summary:
[WARN] Your connection string specifies only a single host.  You should consider adding additional static nodes from your cluster to this list to improve your applications fault-tolerance

Found multiple issues, see listing above.

openssl - yes, the certificate is self-signed, but that’s not a deal-breaker.

openssl s_client -CApath ../server.pem -connect 127.0.0.1:18091
CONNECTED(00000003)
depth=1 CN = Couchbase Server 2f7f91ad
verify error:num=19:self signed certificate in certificate chain
verify return:0
write W BLOCK
---
Certificate chain
0 s:/CN=Couchbase Server Node (127.0.0.1)
i:/CN=Couchbase Server 2f7f91ad
1 s:/CN=Couchbase Server 2f7f91ad
i:/CN=Couchbase Server 2f7f91ad
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDOTCCAiGgAwIBAgIIF2AFDWy/YN4wDQYJKoZIhvcNAQELBQAwJDEiMCAGA1UE
AxMZQ291Y2hiYXNlIFNlcnZlciAyZjdmOTFhZDAeFw0xMzAxMDEwMDAwMDBaFw00
OTEyMzEyMzU5NTlaMCwxKjAoBgNVBAMTIUNvdWNoYmFzZSBTZXJ2ZXIgTm9kZSAo
MTI3LjAuMC4xKTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALY/9GUL
o8bqOFeY4B6LOCdSfYdLiIXb+5VlbNQ0FuZ3wSlNx16neyVLHktp25mU8Utld6Uq
aevyqw4eLI51khrwtxzfME/25jnCZ55W+7aa7RCXmT5znhyhZQXgm7W/dmxLDYTr
k0kBp4Qh15zmVOsYRNBKVsmZlYEVlpavBFgX3vNrsrkVLArZkDPxL2CNq3+n0iKD
fR9dbkcZo6Ps6/vTIxNdWu/x0c1eRoDV7A7zpQpzqPSojnQtWhVIA03IyCT7nrBA
CCtNzcWsm8QyA6bzi1q1UOZfqbeyv99NhbpPBDwqUxiiEzrEX6Re4EvpaBsUDwv0
HYzRTEfT5uahmGcCAwEAAaNnMGUwDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoG
CCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUn2EaQVZx0EgzhMkq
t/yqR/Gr+WMwDwYDVR0RBAgwBocEfwAAATANBgkqhkiG9w0BAQsFAAOCAQEA0ASs
VqWf4HEnTF//ellKLXf/9vqPOHY2dYdOA5nUtsb4HlnK4d7SMXbgG8wgHY9FYuqA
SqSwGGDfb7JRuUM77FKw2EzK8Oj74hcApku3QvdCTcb62P4KSP+wq52VT2Ml8mhQ
HbCfZ1nyT2RpGatrtPHbp9b65GQcQaXWqS8YIltaSdYPiAkeu+9ptEJFcLY/RvoP
0l+gIDqb/ltVZyQEONk/7enO71Zcn7ScK3AA/o8nHrtK41VG4UDry2GbMMHKnt12
nVd43xrpVBvjkAPfh+fXnP0Ls1ZOv+oRBQX3iZBcD6PyGOZcVdVufxzAbf8XHbV
Id7+WTqBdpg8NE2fJg==
-----END CERTIFICATE-----
subject=/CN=Couchbase Server Node (127.0.0.1)
issuer=/CN=Couchbase Server 2f7f91ad
---

No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 2195 bytes and written 367 bytes
---
New, TLSv1/SSLv3, Cipher is AEAD-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.3
Cipher : AEAD-AES256-GCM-SHA384
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1684352779
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
HTTP/1.1 400 Bad Request
Connection: close
Content-Length: 0
Date: Wed, 17 May 2023 19:46:24 GMT
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
closed

I tried your suggestions and came across an error from my side:

I only copied the first certificate!!! With that fixed - the output of the “sdk-doctor” is

|====================================================================|
|          ___ ___  _  __   ___   ___   ___ _____ ___  ___           |
|         / __|   \| |/ /__|   \ / _ \ / __|_   _/ _ \| _ \          |
|         \__ \ |) | ' <___| |) | (_) | (__  | || (_) |   /          |
|         |___/___/|_|\_\  |___/ \___/ \___| |_| \___/|_|_\          |
|                                                                    |
|====================================================================|

Note: Diagnostics can only provide accurate results when your cluster
 is in a stable state.  Active rebalancing and other cluster configuration
 changes can cause the output of the doctor to be inconsistent or in the
 worst cases, completely incorrect.

10:26:59.319 INFO ▶ Parsing connection string `couchbases://127.0.0.1/bucket`
10:26:59.319 INFO ▶ Connection string specifies to use secured connections
10:26:59.319 INFO ▶ Connection string identifies the following CCCP endpoints:
10:26:59.319 INFO ▶   1. 127.0.0.1:11207
10:26:59.319 INFO ▶ Connection string identifies the following HTTP endpoints:
10:26:59.319 INFO ▶   1. 127.0.0.1:18091
10:26:59.319 INFO ▶ Connection string specifies bucket `bucket`
10:26:59.319 WARN ▶ Your connection string specifies only a single host.  You should consider adding additional static nodes from your cluster to this list to improve your applications fault-tolerance
10:26:59.319 INFO ▶ Performing DNS lookup for host `127.0.0.1`
10:26:59.319 INFO ▶ Attempting to connect to cluster via CCCP
10:26:59.319 INFO ▶ Attempting to fetch config via cccp from `127.0.0.1:11207`
10:26:59.321 INFO ▶ Selected the following network type: default
10:26:59.321 INFO ▶ Identified the following nodes:
10:26:59.321 INFO ▶   [0] 127.0.0.1
10:26:59.321 INFO ▶                    kvSSL: 11207,                 mgmt:  8091,              mgmtSSL: 18091
10:26:59.321 INFO ▶                projector:  9999,                 capi:  8092,              capiSSL: 18092
10:26:59.321 INFO ▶                       kv: 11210
10:26:59.321 INFO ▶ Fetching config from `https://127.0.0.1:18091`
10:26:59.325 INFO ▶ Received cluster configuration, nodes list:
[
  {
    "addressFamily": "inet",
    "addressFamilyOnly": false,
    "clusterCompatibility": 458753,
    "clusterMembership": "active",
    "configuredHostname": "127.0.0.1:8091",
    "couchApiBase": "http://172.17.0.3:8092/",
    "couchApiBaseHTTPS": "https://172.17.0.3:18092/",
    "cpuCount": 16,
    "externalListeners": [
      {
        "afamily": "inet",
        "nodeEncryption": true
      }
    ],
    "hostname": "172.17.0.3:8091",
    "interestingStats": {
      "cmd_get": 0,
      "couch_docs_actual_disk_size": 12365731,
      "couch_docs_data_size": 861278,
      "couch_spatial_data_size": 0,
      "couch_spatial_disk_size": 0,
      "couch_views_actual_disk_size": 0,
      "couch_views_data_size": 0,
      "curr_items": 1007,
      "curr_items_tot": 1007,
      "ep_bg_fetched": 0,
      "get_hits": 0,
      "mem_used": 29041568,
      "ops": 0,
      "vb_active_num_non_resident": 0,
      "vb_replica_curr_items": 0
    },
    "mcdMemoryAllocated": 64120,
    "mcdMemoryReserved": 64120,
    "memoryFree": 71641079808,
    "memoryTotal": 84044193792,
    "nodeEncryption": true,
    "nodeHash": 72777219,
    "nodeUUID": "21156f50a862f5aa72cc161c4a81a222",
    "os": "x86_64-pc-linux-gnu",
    "otpNode": "ns_1@127.0.0.1",
    "ports": {
      "direct": 11210,
      "distTCP": 21100,
      "distTLS": 21150,
      "httpsCAPI": 18092,
      "httpsMgmt": 18091
    },
    "recoveryType": "none",
    "serverGroup": "Group 1",
    "services": [
      "kv"
    ],
    "status": "healthy",
    "systemStats": {
      "allocstall": 5812,
      "cpu_cores_available": 16,
      "cpu_stolen_rate": 0,
      "cpu_utilization_rate": 0.265056457810518,
      "mem_free": 71641079808,
      "mem_limit": 84044193792,
      "mem_total": 84044193792,
      "swap_total": 2147479552,
      "swap_used": 51920896
    },
    "thisNode": true,
    "uptime": "590797",
    "version": "7.1.3-3479-enterprise"
  }
]
10:26:59.327 INFO ▶ Successfully connected to Key Value service at `127.0.0.1:11207`
10:26:59.330 INFO ▶ Successfully connected to Management service at `127.0.0.1:18091`
10:26:59.333 INFO ▶ Successfully connected to Views service at `127.0.0.1:18092`
10:26:59.333 WARN ▶ Could not test Query service on `127.0.0.1` as it was not in the config
10:26:59.333 WARN ▶ Could not test Search service on `127.0.0.1` as it was not in the config
10:26:59.333 WARN ▶ Could not test Analytics service on `127.0.0.1` as it was not in the config
10:26:59.335 INFO ▶ Memd Nop Pinged `127.0.0.1:11207` 10 times, 0 errors, 0ms min, 0ms max, 0ms mean
10:26:59.335 INFO ▶ Diagnostics completed

Summary:
[WARN] Your connection string specifies only a single host.  You should consider adding additional static nodes from your cluster to this list to improve your applications fault-tolerance
[WARN] Could not test Query service on `127.0.0.1` as it was not in the config
[WARN] Could not test Search service on `127.0.0.1` as it was not in the config
[WARN] Could not test Analytics service on `127.0.0.1` as it was not in the config

Found multiple issues, see listing above.

The openssl output is similar to yours:

CONNECTED(00000003)
---
Certificate chain
 0 s:CN = Couchbase Server Node (127.0.0.1)
   i:CN = Couchbase Server 236d0f2c
 1 s:CN = Couchbase Server 236d0f2c
   i:CN = Couchbase Server 236d0f2c
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDOTCCAiGgAwIBAgIIF15rPWwqN/MwDQYJKoZIhvcNAQELBQAwJDEiMCAGA1UE
AxMZQ291Y2hiYXNlIFNlcnZlciAyMzZkMGYyYzAeFw0xMzAxMDEwMDAwMDBaFw00
OTEyMzEyMzU5NTlaMCwxKjAoBgNVBAMTIUNvdWNoYmFzZSBTZXJ2ZXIgTm9kZSAo
MTI3LjAuMC4xKTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMb1K7BC
a/uggXaNNz8dAEcWcZg45nRA5if8uzh82kBa+S6otPKFej2/8Ng8DfNOxtn4c4m7
3iH77AnTJBrGCEiq14D1i9tCKYUmdyMSdPKvKw4ZyKkTkzwIopYIel6cMqkSc/yF
bfclt6wnr2wjkKnRGaR8KDovAJ/LRhRlV3A8Ks32BMI91jaT5DXQVpXVIj9oVv+i
cnIJWcX+8PmzLRazBWaNSbXmwYyzSKi1ZH/ld7NxD168/bxMi8RwpsZgag5blf18
maSDHtaCaoy06z6wPVzo0ye8AG7UemBJ1luuKlju7GyLscleaoXsQZxplyeKCn4n
U+G/u5PCT6LiKMcCAwEAAaNnMGUwDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQMMAoG
CCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUo7OHvtHr5KkfJqKm
IBfzfTTlqb0wDwYDVR0RBAgwBocEfwAAATANBgkqhkiG9w0BAQsFAAOCAQEAcwR8
sCjfIiNE66si4lByYekl+GaN+5UxR0IwQdUY2oi5KGMYI1lBLPA/9DZ6dp9JP1dr
svF5rJCMf2BNT44Asw2ZiGBQfZvCR26eIn0v37OlXN9VltscFbjwnOswNTjkRxJM
Q/RanpOoPzKmqVFqiK3gnZ79ncB7hZayenru3b0TL/Dpd51/wnoo9rxcJ2yOsEEA
g/YyiMGZIIb0jtFR85wiFvze4kIjM7/0pzISrytaGoDmdXhWRJY4Iezk4C2NF9fY
DAC3A7FOMd2Ty17WkbmSdYHTuvi4rNzGKi9nTnHgPdJHoBJX3vno6qd9YGavd/tL
erkITpv1SACOwlJjoQ==
-----END CERTIFICATE-----
subject=CN = Couchbase Server Node (127.0.0.1)

issuer=CN = Couchbase Server 236d0f2c

---
Acceptable client certificate CA names
CN = Couchbase Server 236d0f2c
Requested Signature Algorithms: RSA+SHA1:ECDSA+SHA1:RSA+SHA256:RSA+SHA384:RSA+SHA512:Ed448:Ed25519:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA512:Ed448:Ed25519:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2308 bytes and written 393 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self signed certificate in certificate chain)
---

However, my above mentioned test with the C SDK still failed. Hence I tried something different.
I’m compiled the current HEAD version (3.3.7 IIRC) of the libcouchbase C SDK github branch and used the minimal example code.
I get

$ ./minimal "couchbase://127.0.0.1/default?certpath=/tmp/server.pem" Administrator password

Couldn't bootstrap from cluster. Received code 0x3EB (LCB_ERR_SSL_CANTVERIFY (1003))

like in the code written above.
My next step is to check other Couchbase SDKs (Go to specific as it’s the one the sdk-doctor is using IIRC), but to me it looks like it’s a problem/bug in the C SDK? Or am I still missing something? The sdk-doctor is happy - openssl is complaining a bit, but ‘OK’ → the docker container doesn’t seem to be the issue anymore.

@mreiche Could you confirm my observation?

Confirmed the same issue using pillowfight and --certpath.

But - I did find out that specifying root CA ceritficate in the truststorepath does work (with pillowfight, anyway). Try using that in the url :

couchbases://localhost/travel-sample?truststorepath=/users/michaelreiche/server_root.pem

Also - if you append the root CA certificate to /etc/ssl/cert.pem, then openssl no longer complains (don’t need to specify any cert options) and ‘curl’ will also work.

1 Like

I can confirm that using the specifying the certificate via truststorepath does indeed solve the issue for me. Appending the root CA certificate to /etc/ssl/cert.pem also helps to solve the previously mentioned issue with openssl for me.

From my point of view the documentation might need some updates then. Maybe I can help out here by opening a MR? I’ve been digging through some of the doxygen documentation and found it to be confusing in some areas.

You can open an issue at issues.couchbase.com or using the Feedback link on the documentation.
It seems that truststorepath is not mentioned in the C SDK documentation after 3.0.8.
It also seems that some documentation says you can just put the root CA cert (along with the node cert(?)) in the certpath file - but apparently this does not work.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.