SSL Connection with java client 3.5.0

atul · January 19, 2024, 2:14pm

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)

image1632×225 21.9 KB
Enable encryption on the client side and point it to the file containing the certificate.

My Code :

public CouchbaseEncryption() {
    initCluster();
    PasswordAuthenticator passwordAuthenticator = PasswordAuthenticator.builder().username("test").password("test").build();
    couchbaseCluster = Cluster.connect("10.7.xxx.xxx", ClusterOptions.clusterOptions(passwordAuthenticator).environment(couchbaseEnvironment));
}

private static synchronized void initCluster() {
    if(couchbaseEnvironment == null) {           
        try {
        couchbaseEnvironment = ClusterEnvironment.builder()
                .securityConfig(SecurityConfig
                        .enableTls(true)
                        .trustCertificate(Paths.get("/path/to/cluster.cert"))
                .build();
        } catch (URISyntaxException e) {
           throw new RuntimeException(e);
        }
    }
}

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?

mreiche · January 19, 2024, 4:03pm

“use couchbases:// in your connection string”

Also - when you reach out for help with an error, it helps to show the error.

david.nault · January 19, 2024, 6:10pm

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:

public CouchbaseEncryption() {
  String username = "test";
  String password = "test";
  couchbaseCluster = Cluster.connect(
    "couchbases://10.7.xxx.xxx?certpath=/path/to/cluster.cert",
    username,
    password
  );
}

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.

Thanks,
David

david.nault · January 19, 2024, 8:44pm

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.

Thanks,
David

atul · January 22, 2024, 6:10am

Thanks @david.nault @mreiche for prompt response, here is my CB connection code as per suggestion,

String username = “test”;
String password = “test”;
couchbaseCluster = Cluster.connect(
“couchbases://10.7.xxx.xxx?certpath=/path/to/cluster.cert”,
username,
password
);

But it is throwing exception:
“sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested”

I tried to resolve it by following ways:

Added certificate to default Java Truststore - cacerts :

keytool -import -alias myCert -file C://certificate.cert -keystore $JAVA_HOME/lib/security/cacerts

Created a Trust Store and passed it as JVM argument:

keytool -import -alias myCert -file C://certificate.cert -keystore myTrustStore
-Djavax.net.ssl.trustStore=C://myTrustStore
-Djavax.net.ssl.trustStorePassword=changeit

Could you please help on this?

atul · January 22, 2024, 7:12am

Connection is working with tls_verify=none that means connection failure is due to certificate issues.

mreiche · January 22, 2024, 4:06pm

start over from the beginning and follow the documentation exactly.

make sure you are specifying the root certificate
use only the option trustCertificate(path) mechanism. Mixing multiple mechanisms makes it difficult to determine what is wring.
the openssl command can be used to troubleshoot ssl issues. Google “Troubleshooting SSL”

david.nault · January 22, 2024, 5:25pm

^-- Did you try this?

atul · January 29, 2024, 4:57pm

@david.nault
For development/test environment we have only one node as below,

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

david.nault · January 29, 2024, 5:36pm

HI @atul ,

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.

Thanks,
David