Gyula Komlossi created FLINK-40329:
--------------------------------------
Summary: Support Single EKU certificates for server and client TLS
authentication
Key: FLINK-40329
URL: https://issues.apache.org/jira/browse/FLINK-40329
Project: Flink
Issue Type: Improvement
Components: Runtime / Configuration
Reporter: Gyula Komlossi
h4. *Problem & Background*
Starting in May 2026, major public Certificate Authorities (Let's Encrypt,
DigiCert, Sectigo, etc.) are sunsetting the {{clientAuth}} Extended Key Usage
(EKU) on publicly issued leaf certificates. Public certificates will only carry
the {{serverAuth}} EKU going forward.
As a result, a single publicly issued TLS certificate can no longer serve
dual-purpose role for both server and client authentication in mutual TLS
(mTLS) setups.
For Flink deployments that rely on mTLS (e.g., RPC communication, REST
endpoints, or internal cluster connections), renewed public CA certificates
will fail the TLS handshake during client certificate validation because the
{{clientAuth}} EKU will be missing.
h4. *Proposed Improvement*
To support the hybrid model (using public CAs for server identity and
private/internal CAs for client identity), Flink needs expanded TLS
configuration options.
Specifically, Flink should allow users to configure separate Keystores and
Truststores (or distinct certificate pathways) for:
# *Server Authentication:* Presenting public-CA certificates
({{{}serverAuth{}}} EKU only).
# *Client Authentication:* Presenting internal/private-CA certificates
({{{}clientAuth{}}} EKU).
h4. *Reference*
* *ASF Blog:* [The Public CA clientAuth EKU Sunset: What Apache Software
Deployers Need to
Know|https://news.apache.org/foundation/entry/the-public-ca-clientauth-eku-sunset-what-apache-software-deployers-need-to-know]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
