[
https://issues.apache.org/jira/browse/FLINK-40329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gyula Komlossi updated FLINK-40329:
-----------------------------------
Description:
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]
was:
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]
> 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
> Priority: Major
>
> 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)
