[efegokdemir]

Summary

When only a key store or trust store location is configured, the SSL configuration factory passes a null store type to password handling and throws a NullPointerException. Use Log4j's existing default key store type for password selection while retaining the existing configuration defaulting behavior.

Changes

• Handle a missing key/trust store type using SslConfigurationDefaults.KEYSTORE_TYPE.
• Add regression coverage for a key store location without an explicit type.
• Add the required 2.x changelog entry.

Fixes #4346

Testing

• git diff --check — passed
• xmllint --noout src/changelog/.2.x.x/4346_default_keystore_type.xml — passed
• ./mvnw -pl log4j-core-test -Dtest=SslConfigurationFactoryTest test — blocked locally because the available runtime is Java 8 while the build requires newer JDK options (--add-exports).

[ramanathan1504]

The default in getPassword covers both call sites, and the new test fails with the NPE from #4346 without it.
Two small points inline, on SslConfigurationFactory and its test.

[efegokdemir]

Updated in bbb6959.

• Added a trust-store-location-without-type regression alongside the key-store case.
• Made JKS/PKCS12 password handling case-insensitive, matching AbstractKeyStoreConfiguration and Java 9+ default pkcs12 behavior.
• Added PR #4359 to the changelog entry alongside issue #4346.

git diff --check passes. The focused Maven test could not start locally because only Java 8 is installed and the wrapper requires --add-exports; CI should validate the supported JDK matrix.

[ramanathan1504]

@efegokdemir
No test covers the equalsIgnoreCase change in getPassword. With a null password the JDK loads keyStore-nopass.p12 without its certificate.
Can SslConfigurationFactoryTest load that file with an empty log4j2.keyStorePassword and no type, and check the certificate is there? The build needs JDK 17 to run the tests locally. BUILDING.adoc has the setup.