Hi, I am trying to use

KafkaConfluentSchemaRegistryAvroMessageDecoder

We have a schema registry set up with SSL authentication. I am getting

SSLHandshakeException

Wondering what is the proper way to pass the SSL certs config for the schema registry client? I digged a bit into the code, it seems like pinot needs to update the schema-registry-client to include this (https://github.com/confluentinc/schema-registry/pull/957) with some code changes. Can be accomplished without it too. Wanted to check before if there is an alternative way to accomplish this?

Hi Pradeep, will take a look. Can you share your schema registry client config that you use, i.e. to get a SchemaRegistryClient (you can obfuscate the keys, etc.)?

These are the extra keys we usually pass “schema.registry.ssl.truststore.location”: “”, “schema.registry.ssl.keystore.location”: “”, “schema.registry.ssl.truststore.password”: “”, “schema.registry.ssl.keystore.password”: “”, “schema.registry.ssl.key.password”: “”,

Will take a look and get back to you

thanks

@Pradeep I haven't tested that specific use case but the SR client should reuse the default ssl settings of the JVM. Have you tried setting the typical

-Dssl.*

on the pinot JVMs?

I tried that not sure why it is not working, this is the final command used to bring up the pinot-server /usr/bin/java -Xms4G -Dlog4j2.configurationFile=conf/pinot-admin-log4j2.xml -Dplugins.dir=/home/ubuntu/main/apache-pinot-incubating-0.5.0-SNAPSHOT-bin/plugins -classpath /home/ubuntu/main/apache-pinot-incubating-0.5.0-SNAPSHOT-bin/lib/* -Djavax.net.ssl.trustStore=<filepath> -Djavax.net.ssl.trustStorePassword=<password> -Djavax.net.ssl.keyStore=<filepath> -Djavax.net.ssl.keyStorePassword=<password> -Dapp.name=pinot-admin -Dapp.pid=21655 -Dapp.repo=/home/ubuntu/main/apache-pinot-incubating-0.5.0-SNAPSHOT-bin/lib -Dapp.home=/home/ubuntu/main/apache-pinot-incubating-0.5.0-SNAPSHOT-bin -Dbasedir=/home/ubuntu/main/apache-pinot-incubating-0.5.0-SNAPSHOT-bin org.apache.pinot.tools.admin.PinotAdministrator StartServer -configFileName /home/ubuntu/serverConfig -zkAddress <zkaddr> I still see ssl auth exception which is weird, since we use a similar method for at other places. Maybe the issue is because pinot is explicitly creating the Cache SR?

Exception while in work
org.apache.kafka.common.errors.SerializationException: Error deserializing Avro message for id 34
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:198) ~[?:1.8.0_252]
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1967) ~[?:1.8.0_252]
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:331) ~[?:1.8.0_252]
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:325) ~[?:1.8.0_252]
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1688) ~[?:1.8.0_252]
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226) ~[?:1.8.0_252]
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1082) ~[?:1.8.0_252]
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:1010) ~[?:1.8.0_252]
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1079) ~[?:1.8.0_252]
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1388) ~[?:1.8.0_252]
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1416) ~[?:1.8.0_252]
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1400) ~[?:1.8.0_252]
        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) ~[?:1.8.0_252]
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) ~[?:1.8.0_252]

Can you activated the SSL debug tracing? This will provide handshake dump and confirm that the problems resides in the keystores being empty and not the certificate being invalid.

I have modified the code to create the cachedschemaregistry with certs passed to it. Then I don't see the exception

Sure, nice!!!