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.