Fixing “trustAnchors Parameter Must Be Non-Empty” Error After Excluding spring-security-crypto in Spring Boot 2

If you’re working on a Spring Boot 2 application integrated with Apache Camel, you may have encountered the perplexing “trustAnchors parameter must be non-empty” runtime error. It commonly pops up when you try to exclude a specific dependency, especially the spring-security-crypto library from your Gradle configuration. While it’s tempting to simply cut out that dependency to tackle security issues, it often triggers unexpected runtime exceptions that leave many developers scratching their heads.

But why does excluding something like spring-security-crypto lead to a totally different and seemingly unrelated security error? We’ll explain the root causes behind it, share step-by-step solutions on safely fixing the issue, and guide you through best practices for maintaining secure Spring Boot apps.

Background: CVE-2025-22228 and Dependency Management

Recently, Spring Security Crypto library version 5.7.6 was identified with a security vulnerability flagged as CVE-2025-22228. Essentially, applications running this version face risks involving cryptographic operations. Naturally, developers respond by excluding or upgrading dependencies, aiming to mitigate risk.

In this case, suppose you’re using Spring Boot 2.x along with Apache Camel 3.22.4. Both frameworks may rely on the crypto library indirectly or explicitly. Your Gradle file might look exactly like this:


implementation 'org.springframework.boot:spring-boot-starter-web:2.x.x'
implementation 'org.apache.camel.springboot:camel-spring-boot-starter:3.22.4'
implementation 'org.springframework.security:spring-security-crypto:5.7.6' // Vulnerable dependency

Removing spring-security-crypto becomes an instinctive fix to eliminate vulnerability warnings—or so we think. However, doing this triggers an entirely different runtime error.

Understanding the Runtime Error

When you deploy the Spring Boot application after excluding spring-security-crypto, a seemingly cryptic error pops up. It looks something like this:


java.lang.RuntimeException: Unexpected exception during SSL context initialization
...
Caused by: java.security.InvalidAlgorithmParameterException: trustAnchors parameter must be non-empty
    at sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:49)
    ...

What this error essentially tells you is that your application tried to establish SSL connections but couldn’t find any trusted SSL certificates (“trustAnchors”). For secure connections (like HTTPS REST APIs or external Camel routes), the JVM needs access to a populated truststore—effectively a collection of trusted Certificate Authorities (CAs). When the truststore is empty or misconfigured, Java throws the dreaded “trustAnchors parameter must be non-empty” error.

Why Does Excluding the Crypto Dependency Trigger This?

Great question! You’d think removing a potentially vulnerable cryptographic library would be helpful. But Spring Security Crypto provides core cryptographic functions—especially around secure random number generators, hashing, and cryptographic setups. These setups indirectly support SSL contexts, keystores, and truststores.

Removing this crucial dependency unintentionally disrupts cryptographic initialization processes. It results in an empty truststore, which fundamentally breaks SSL/TLS connections. Thus, your security fix inadvertently introduces a different security gap by disabling proper certificate and SSL management.

How to Safely Resolve the Issue Step-by-Step

The good news? Resolving this issue doesn’t have to be complicated. Here’s an actionable step-by-step approach to safely removing the library while preventing the trustAnchors error:

Exclude the vulnerable dependency properly from Gradle. Open your build.gradle, and adjust the exclusion correctly:


implementation('org.springframework.boot:spring-boot-starter-web:2.x.x') {
    exclude group: 'org.springframework.security', module: 'spring-security-crypto'
}

implementation('org.apache.camel.springboot:camel-spring-boot-starter:3.22.4') {
    exclude group: 'org.springframework.security', module: 'spring-security-crypto'
}

Explicitly include an updated and secure replacement version. Pick a secure version without known issues, such as:
```
implementation 'org.springframework.security:spring-security-crypto:5.8.8'
```
Verify latest secure options on Spring’s official Maven repository or Maven Central.
Check your truststore configuration. Ensure the JVM has a properly configured truststore. By default, Java references the cacerts located under:
```
$JAVA_HOME/jre/lib/security/cacerts
```
Make sure this file contains valid CA certificates. You can verify its existence using:
```
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts
```
Set the keystore property explicitly in your Spring Boot application.properties file if needed:
```
server.ssl.trust-store=classpath:truststore.jks
server.ssl.trust-store-password=yourpassword
server.ssl.trust-store-type=JKS
```

Alternative Solutions & Best Practices

Besides Gradle-level fixes highlighted above, consider these alternative methods:

Generate a new truststore file: Use keytool to create and populate a new truststore with necessary CA certificates.
Java Security Update: Update your Java and underlying libraries regularly, ensuring access to recent security patches.
Use Dependency Management Tools: Tools like Gradle Dependency Locking and OWASP Dependency-Check can proactively track vulnerabilities and recommend safer versions.
Continuous Monitoring: Incorporate vulnerability scanners into your CI/CD pipelines to identify issues early and tighten security proactively.

Testing Your Update & Verifying the Fix

Addressing dependency-related issues requires thorough validation. To validate your fix, follow these recommendations:

Integrate automated tests: Safeguard your runtime with integration tests specifically checking your application’s SSL endpoints or Camel routes.
Manual testing: Perform manual smoke tests on SSL-enabled features to guarantee no regression.
Monitoring: Continuously monitor logs and application performance to catch cryptographic issues swiftly.

You can also leverage tools like the SSL Labs Test, which performs independent checks to validate SSL setup comprehensively.

Finally, make a conscious effort to pay attention to application security protocols around SSL/TLS setups, keystores, and cryptographic libraries. It’s beneficial to regularly consult Spring Boot’s official security guidelines and Apache Camel documentation to stay updated.

After resolving the error, make sure to address why the dependency became problematic in the first place. Document it properly, discuss it within your development team, and commit to regular updates or patches moving forward.

Have you encountered a similar SSL misconfiguration issue recently? How do you approach managing security concerns in your Spring Boot projects? Share your experience below—let’s help each other build secure, robust, and reliable apps.