ppkarwasz opened a new issue, #4332: URL: https://github.com/apache/logging-log4j2/issues/4332
When a `TrustStore` (or `KeyStore`) element of `Ssl` cannot be loaded, for example because the file is missing or the password is wrong, `TrustStoreConfiguration#createKeyStoreConfiguration` throws `StoreConfigurationException`, `PluginBuilder` logs an error and returns `null` for the element, and `SslConfiguration#createSSLConfiguration` receives `null` exactly as if the element had been absent. The `SSLContext` is then initialized with `null` trust managers, i.e. the JVM default trust store. Independently, `SslConfiguration#createSslContext` catches any initialization error and falls back to `SSLContext.getDefault()`. This is **not** a vulnerability: the configuration is trusted input under the [threat model](https://logging.apache.org/security.html#threat-common-sources-configuration) and the failure is reported at ERROR level by the status logger. It is, however, a fail-open behavior for a security-relevant element: a deployer who restricted trust to a private CA ends up with the default trust store after a password rotation or a missing volume mount. This issue originates from a private security report classified as hardening. Proposal: when a `KeyStore` or `TrustStore` child element is present but invalid, the `Ssl` element should fail to build and the enclosing appender should fail to start. One way is to let the store factories return a configuration object that records the failure instead of throwing, and have `SslConfiguration` reject it; the default-context fallback in `createSslContext` should also be removed. This fits the TLS configuration rework tracked in #2792 and #3902. Reported by @August829 -- 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]
