Upgrading from Java 8 to Java 11 caused an issue with Kafka admin client when connecting with SSL with the following error:

[2022-06-10 11:31:53,520] [kafka-admin-client-thread | adminclient-1] (org.apache.kafka.common.network.Selector:609) WARN [AdminClient clientId=adminclient-1] Unexpected error from localhost; closing connection (org.apache.kafka.common.network.Selector)
java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
	at java.base/sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:102)
	at java.base/sun.security.validator.Validator.getInstance(Validator.java:181)
	at java.base/sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:300)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:176)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:246)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:632)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:473)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
	at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
	at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
	at org.apache.kafka.common.network.SslTransportLayer.runDelegatedTasks(SslTransportLayer.java:402)
	at org.apache.kafka.common.network.SslTransportLayer.handshakeUnwrap(SslTransportLayer.java:484)
	at org.apache.kafka.common.network.SslTransportLayer.doHandshake(SslTransportLayer.java:340)
	at org.apache.kafka.common.network.SslTransportLayer.handshake(SslTransportLayer.java:265)
	at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:170)
	at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:536)
	at org.apache.kafka.common.network.Selector.poll(Selector.java:472)
	at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:535)
	at org.apache.kafka.clients.admin.KafkaAdminClient$AdminClientRunnable.run(KafkaAdminClient.java:1131)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
	at java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
	at java.base/java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)
	at java.base/java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)
	at java.base/sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:99)
	... 24 more

Turns out the admin client was expecting a truststore format of ssl.truststore.type = JKS, however, in java 9+ the default keystore type generated when using keytool is set to PKCS12. Adding the flag -storetype JKS to keytool reverts to the old JKS format and fixes the issue.