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?
Comment From: 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:
https://github.com/spring-projects/spring-boot/blob/8a9ce28b98367a582370cabe8670bbcc4e4fcee1/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/couchbase/CouchbaseAutoConfiguration.java#L267-L277
There's also a test that verifies that this arrangement results in TLS being enabled on the security config:
https://github.com/spring-projects/spring-boot/blob/8a9ce28b98367a582370cabe8670bbcc4e4fcee1/spring-boot-project/spring-boot-autoconfigure/src/test/java/org/springframework/boot/autoconfigure/couchbase/CouchbaseAutoConfigurationTests.java#L195-L202
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.
Comment From: 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.
Comment From: 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.