[
https://issues.apache.org/jira/browse/KAFKA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18013566#comment-18013566
]
oshione gabriel esiemokhai commented on KAFKA-19556:
----------------------------------------------------
if you disable sni how then can you locate different host names in the same web
server ?
> [Connect] Provide a configuration to disable SNI required and SNI host
> checking for the REST API
> ------------------------------------------------------------------------------------------------
>
> Key: KAFKA-19556
> URL: https://issues.apache.org/jira/browse/KAFKA-19556
> Project: Kafka
> Issue Type: Bug
> Components: connect
> Affects Versions: 4.0.0
> Reporter: Tamas Kornai
> Priority: Major
>
> h3. Summary
> The upgrade to Jetty 12 in Kafka 4.0 enables a strict SNI host check by
> default for the Connect REST API. This change breaks HTTPS request forwarding
> between Connect workers when they connect via IP address, causing requests to
> fail with a 400: Invalid SNI error.
> h3. The Problem
> Prior to Kafka 4.0, the Jetty server used for the Connect REST API did not
> enforce a strict match between the TLS SNI hostname and the HTTP Host header.
> With the upgrade to Jetty 12, this check is now enabled by default at the
> HTTP level. This causes legitimate HTTPS requests to fail in environments
> where the client connects using an IP address or a hostname that is not
> listed in the server's TLS certificate.
> This results in the following error:
> {code:java}
> org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> {code}
> h3. Impacted Use Case: Inter-Node Request Forwarding
> This change specifically breaks the request forwarding mechanism between
> Connect workers in a common deployment scenario:
> # A follower Connect instance needs to forward a REST request to the leader.
> # The follower connects directly to the leader's IP address over HTTPS.
> # Security is handled by mTLS certificates, often managed by a custom
> certificate provider.
> This setup worked flawlessly before Kafka 4.0. Now, because the follower
> connects via IP, the SNI check fails, and the forwarding mechanism is broken.
> h3. Proposed Solution
> This behavior cannot be disabled through any existing Kafka Connect
> configuration. To restore the previous functionality, a
> SecureRequestCustomizer must be programmatically configured in
> RestServer.java to disable the SNI required and the SNI host check flags.
> This should be driven by a configuration value that allows disabling these
> SNI related settings.
> {code:java}
> // In RestServer.java, when building the HTTPS connector
> SecureRequestCustomizer customizer = new SecureRequestCustomizer();
> customizer.setSniRequired(false);
> customizer.setSniHostCheck(false);
> HttpConfiguration https = new HttpConfiguration();
> https.addCustomizer(customizer);
> connector = new ServerConnector(jettyServer, ssl, new
> HttpConnectionFactory(https)); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
