Couchbase TLS regression when autoconfiguring without SSL Bundle

[davidjlynn]

Issue

While upgrading from Spring Boot 3.4.x to 3.5.x I have noticed a regression/change in behaviour of how Spring Boot Autoconfigure sets up TLS, in particular for Couchbase.

Couchbase supports TLS while using the default certificates through the JVM:
Couchbase SecurityConfig

And in Spring Boot 3.4.x it was possible to enable this behaviour by specifying the property:

spring:
  couchbase:
    env:
      ssl:
        enabled: true

With no need for an SSL bundle, Spring Boot would set up TLS during autoconfigure without a truststore, and couchbase would fetch the default certificates.

The change in behaviour seems to have been introduced here: Commit during #41137.

Where now, an SSL bundle is required to setup TLS. This appears to have been changed in 3.5.0.

Workaround

To workaround the issue, I can create a customizer to set TLS to enabled:

@Configuration
public class CouchbaseConfig {
  @Bean
  public ClusterEnvironmentBuilderCustomizer clusterEnvironmentBuilderCustomizer(){
    return builder -> builder.securityConfig().enableTls(true);
  }
}

It would be good to know if this behaviour was intentionally removed and we should continue with the workaround, or if this should be supported?

[wilkinsona]

Where now, an SSL bundle is required to setup TLS.

That shouldn't be the case. With SSL enabled but no SSL bundle configured, the auto-configuration will implicitly use the system defaults SSL bundle:

spring-boot/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/couchbase/CouchbaseAutoConfiguration.java

Lines 267 to 277 in 8a9ce28

	public SslBundle getSslBundle() {
	Ssl ssl = this.properties.getEnv().getSsl();
	if (!ssl.getEnabled()) {
	return null;
	}
	if (StringUtils.hasLength(ssl.getBundle())) {
	Assert.notNull(this.sslBundles, "SSL bundle name has been set but no SSL bundles found in context");
	return this.sslBundles.getBundle(ssl.getBundle());
	}
	return SslBundle.systemDefault();
	}

There's also a test that verifies that this arrangement results in TLS being enabled on the security config:

spring-boot/spring-boot-project/spring-boot-autoconfigure/src/test/java/org/springframework/boot/autoconfigure/couchbase/CouchbaseAutoConfigurationTests.java

Lines 195 to 202 in 8a9ce28

	@Test
	void enableSsl() {
	testClusterEnvironment((env) -> {
	SecurityConfig securityConfig = env.securityConfig();
	assertThat(securityConfig.tlsEnabled()).isTrue();
	assertThat(securityConfig.trustManagerFactory()).isNotNull();
	}, "spring.couchbase.env.ssl.enabled=true");
	}

It sounds like that's not working for you, but I cannot tell why based on what you've shared thus far.

If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

[davidjlynn]

Thanks for the quick response and analysis.

I have taken a deeper look with some debugging side by side before/after the update and now have a much better idea of what is happening thanks to your feedback.

An important note is that we use Couchbase Capella.

While debugging before/after, I noticed some behaviour has changed when the underlying couchbase client library is set up.
And a note that the behaviour you have described above is correct of what happens now.

Previously (SB 3.4.7) the behaviour would be:

• In SB's CouchbaseAutoConfiguration.configureSsl
  • Set enableTls to true.
  • Do not set trustManagerFactory
• Which when built in CB's SecurityConfig
  • Default fallback behaviour is applied because of null trustMangerFactory, where CB libraries go and fetch BOTH the JVM CAs AND Capella's CAs

However now, (SB 3.5.3) the behaviour seems to be:

• In SB's CouchbaseAutoConfiguration.configureSsl
  • Set enableTls to true.
  • We set trustManagerFactory to the default SSL Bundle.
• Which when built in CB's SecurityConfig
  • We will use the default SSL Bundle that was passed, which provides JUST the JVM CAs

The important default behaviour is here: SecurityConfig

So apologies, my description above was incorrect, indeed TLS is enabled, but the certificates that were previously included have changed because of CB's behaviour of previously including the Capella CAs.

I am still not sure whether this deserves a fix in SB, given the analysis above. The now implemented behaviour seems like a good standard to be applying. But maybe worth noting during release upgrades that users of Couchbase Capella may find issues when upgrading if they are using the default behaviour.

With the extra information I have a better workaround now:

spring:
  ssl:
    bundle:
      pem:
        couchbase-bundle:
          truststore:
            # Note that this certificate is fetched from the `com.couchbase.client:code-io` dependency.
            certificate: classpath:com/couchbase/client/core/env/capella-ca.pem
  couchbase:
    env:
      ssl:
        bundle: couchbase-bundle

Where due to the use of Capella we deliberately specify the Capella certificates (Which we fetch from the couchbase libraries where they were retrieved from before).
This appears to be working.

[wilkinsona]

Thanks very much, @davidjlynn. I've added something to the 3.5 release notes so that others can benefit from what you've figured out.