oscerd opened a new pull request, #27824: URL: https://github.com/apache/camel/pull/27824
## Summary [CAMEL-25645](https://issues.apache.org/jira/browse/CAMEL-25645) `milo-client` and `milo-browse` built the Eclipse Milo client configuration without a certificate validator, so they kept Milo's default, `CertificateValidator.InsecureCertificateValidator`, and the certificate of a server offering a Sign or SignAndEncrypt endpoint was not checked. The client had no option to configure trust material. This PR: - adds three client options, at component and endpoint level, shared by `milo-client` and `milo-browse`: - `trustListDirectory`: a trust list in Eclipse Milo's file based layout (`trusted/certs`, `trusted/crl`, `issuer/certs`, `issuer/crl`). A rejected server certificate is written to `rejected/certs`. - `certificateValidator`: a custom `CertificateValidator` bean, used instead of the trust list. It is not autowired. - `trustAllCertificates`: accept any server certificate, marked `security = "insecure:ssl"`. - validates the server certificate whenever the selected endpoint uses a security policy other than `None`. When neither `trustListDirectory` nor `certificateValidator` is set and `trustAllCertificates` is false, the client does not connect, and the reason is logged. - uses the same validator for the secure channel, the session and the `UsernameProvider` that encrypts the user name and password. - creates the file based trust list once per connection, and closes it when the connection is disposed, since it watches its directories. - adds the trust settings to the connection cache id, so endpoints that validate the server differently no longer share a connection. - documents the options in `milo-client-component.adoc`, in a new "Validating the server certificate" section, recommends restricting `allowedSecurityPolicies`, and adds a 4.24 upgrade guide entry. Endpoints that use the security policy `None` are not affected. ## Tests - `ServerCertificateTrustTest`: the choice of validator (refusal without trust configuration on a secured endpoint, `None`, `trustAllCertificates`, precedence of `certificateValidator`), a trusted certificate accepted, an untrusted one rejected and written to `rejected/certs`, and a closed trust list not reused. - `MiloClientConfigurationTest`: the cache id is unchanged without trust settings and differs with them; copy and clone keep the settings. - `ServerCertificateValidationTest`: a server that only offers a `Basic256Sha256` endpoint. The clients with a trust list holding the server certificate, with `trustAllCertificates=true`, or with a `certificateValidator` bean receive the monitored value. The clients with an empty trust list or without trust configuration do not, and the rejected certificate is written to the trust list. - camel-milo module: 54 tests, 0 failures, 1 skipped (`MonitorItemMultiConnectionsCertTest`, already `@Disabled`). A full reactor build regenerated the catalog, the DSL factories and `SecurityUtils`. - With the previous behaviour forced back in, `ServerCertificateValidationTest` fails: the client without trust configuration receives the monitored value from the secured server. `MonitorItemMultiConnectionsCertTest` is still `@Disabled`, as before. The new test sets up the secured server through the component's `certificateManager` option. ## Upgrade Clients that use a secured security policy need `trustListDirectory` or `certificateValidator` after upgrading. `trustAllCertificates=true` restores the previous behaviour, which is insecure. _Claude Code on behalf of Andrea Cosentino_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
