DaDavides opened a new issue, #21240:
URL: https://github.com/apache/pulsar/issues/21240

   ### Search before asking
   
   - [X] I searched in the [issues](https://github.com/apache/pulsar/issues) 
and found nothing similar.
   
   
   ### Version
   
   Pulsar v 3.1.0
   
   ### Minimal reproduce step
   
   Generate a certificate for localhost, for example  
https://www.section.io/engineering-education/how-to-get-ssl-https-for-localhost/
   
   Setup a Keycloak server (Docker v22) that only accepts TLSv1.3. Start a 
container  with 
   ```
   docker run --rm -it --network host --name keycloak \
   -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=changeit \
   -v `pwd`/certs/localhost.pem:/opt/keycloak/localhost.pem \
   -v `pwd`/certs/localhost.key/opt/keycloak/localhost.key \
   quay.io/keycloak/keycloak:22.0 start-dev --hostname localhost 
--http-enabled=false --https-protocols=TLSv1.3 
--https-certificate-file=/path/to/localhost.pem 
--https-certificate-key-file=/path/to/localhost.key
   ```
   
   Configure a Pulsar 3.1.0 cluster using OIDC authentication, a standalone 
version is the easiest. 
   
   
   ### What did you expect to see?
   
   I would expect all requests between Pulsar and Keycloak to be able to use 
TLSv1.3.
   
   ### What did you see instead?
   
   Debugging the TLS handshake, the initial communication goes well, with both 
`ClientHello.extensions.supported_versions.versions` and  
`ServerHello.extensions.supported_versions.selected_version` having TLSv1.3 as 
value. The problem arises after the log says 
"org.apache.pulsar.functions.worker.Workerutils - Create Pulsar Admin to 
service ..." and the `AsyncHttpClient` starts its TLS handshake. The failing 
ClientHello has TLSv1.2 in 
`ClientHello.extensions.supported_versions.versions`. 
   
   ### Anything else?
   
   We've tried to set different Pulsar runtime options using 
`PULSAR_EXTRA_OPTS` to control protocol version but they don't seem to be 
honoured. Yes, we've verified that the `PULSAR_EXTRA_OPTS` environment 
variables are set in the docker container.
   
   Just to verify, we made a simple java class that fetches the realm info from 
Keycloak using a simple java.net.HttpURLConnection. Running the class with 
`-Djdk.tls.client.protocols=TLSv1.3` it works and using `TLSv1.2`it fails, as 
expected as Keycloak requires the former version and is not accepting the 
latter.
   
   Is it possible to force the TLS version in some other way? 
   
   Or is it known problem? We've found a similar issue in Quarkus with a 
dependency to vertx, but not sure if it is related 
https://github.com/quarkusio/quarkus/issues/29635
   
   The runtime options we added to Pulsar were:
   PULSAR_EXTRA_OPTS="-Dhttps.protocols=TLSv1.3 
-Dhttps.client.protocols=TLSv1.3 -Djdk.tls.client.protocols=TLSv1.3 
-Djavax.net.debug=ssl:handshake"
   
   Unfortunately, we don't have the customers permission to share any logs.
   
   ### Are you willing to submit a PR?
   
   - [ ] I'm willing to submit a PR!


-- 
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]

Reply via email to