We are using Couchbase Enterprise Edition 7.1.4 and Java client 3.5.0.
Currently there is default unencrypted connection and now we are going to secure the connection using TLS. For that I am following below link: Secure Connection
As mentioned in the link, I have performed below steps but those are not working:
Get the CA certificate from the cluster and save it in a text file.
(Copied CA certificate from admin UI Security-> Certificates)
As I am new to SSL not sure If I am missing anything. So my question is, for testing purpose can we use default CA certificate (enterprise edition) for java client connection?
Hi @atul! Welcome, and thanks for joining the Couchbase Forum.
Some general code review notes:
Unless you are creating many Cluster objects, I’d recommend letting the cluster manage the ClusterEnvironment instead of building your own. That way you don’t need to remember to shut down the environment after it’s no longer needed.
Here’s what it would look like to let the Cluster manage its own environment:
public CouchbaseEncryption() {
String connectionString = "10.7.xxx.xxx";
String username = "test";
String password = "test";
couchbaseCluster = Cluster.connect(
connectionString,
ClusterOptions.clusterOptions(username, password)
// Instead of passing a pre-built ClusterEnvironment,
// pass a callback that configures a ClusterEnvironment.Builder.
.environment(env -> env
.securityConfig(security -> security
.enableTls(true)
.trustCertificate(Paths.get("/path/to/cluster.cert"))
)
)
);
}
You could simplify this further by using the connection string to customize the environment. Here’s an example that enables TLS by using the couchbases:// scheme, and configures the trusted CA certificate using the “certpath” parameter:
With that out of the way, let’s think about the problem you’re facing. The Couchbase SDK verifies that the certificate presented by the server is associated with the address used to connect to the server. It’s possible the certificate requires you to use a hostname (like couchbase.example.com) instead of an IP address (like 10.7.xxx.xxx). If you look at the server list in the Couchbase Admin UI, how does that page display the addresses? Does changing the connection string to use those addresses help?
If that doesn’t solve the problem, please share the error you’re seeing so we can try to help diagnose it.
In a self-hosted deployment, each cluster generates a unique root certificate, so there isn’t really a concept of a “default certificate.” If you want, you can configure the server to use a specific certificate. See Configure Server Certificates | Couchbase Docs
Alternatively, in your dev environment you could configure the client to skip certificate verification. This is not secure, but can be a useful tool for diagnosing whether a connection failure is due to certificate issues. To try it, include the tls_verify=none parameter in your connection string. Just be extra careful not to use this feature in a production environment.
In Code, my connection string is “couchbases://10.7.200.139”
Getting below error while connecting to CB
[com.couchbase.io][SecureConnectionFailedEvent] Detected a TLS problem in the IO layer: javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem, Cause: java.security.cert.CertificateException: No subject alternative names matching IP address 10.7.200.139 found {“coreId”:“0xd15b7f7b00000003”,“local”:“/172.22.0.3:46678”,“remote”:“10.7.200.139/10.7.200.139:11207”}
2024-01-29T13:38:01,515 WARN [cb-events ] c.c.endpoint : [com.couchbase.endpoint][EndpointConnectionFailedEvent][13ms] Connect attempt 1 failed because of DecoderException: javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem {“circuitBreaker”:“DISABLED”,“coreId”:“0xd15b7f7b00000003”,“remote”:“10.7.200.139:11207”,“type”:“KV”}
com.couchbase.client.core.deps.io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem
at java.lang.Thread.run(Unknown Source) ~[?:?]
Caused by: javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem
at javax.net.ssl.SSLEngine.wrap(Unknown Source) ~[?:?]
… 1 more
Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address 10.7.200.139 found
at sun.security.util.HostnameChecker.matchIP(Unknown Source) ~[?:?]
at sun.security.util.HostnameChecker.match(Unknown Source) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(Unknown Source) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(Unknown Source) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source) ~[?:?]
… 1 more
My guess is that the server is presenting a certificate for 127.0.0.1 (because that’s the address it was configured to use during cluster setup), but the client requires a certificate for 10.7.200.139.
Since this is a single-node cluster, you can use the REST API to rename the node to give it its true name of 10.7.200.139. See Naming a Node | Couchbase Docs
I’m optimistic this will cause the server to present a certificate for the new name. If I’m wrong about that, something that would definitely work would be to take down the current cluster, and create a new one configured to use the correct name from the start. If that’s not an option, you could ask the folks in the Couchbase Server part of the forum for advice about configuring the server certificate.
