[
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 #1*
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. *Proposed Improvement #2 (recommended)*
Another way to support the single EKU certificates, if Flink can handle
multiple certificates in one keystroke. This way the {{serverAuth}} EKU
certificates, provided by a public CA and an internal one for {{clientAuth}}
also delivered in the same keystone, so no change is required in the
configuration options.
The only thing that needs to be verified, if the used KeyManagerFactory is able
to pick the right certificate when needed. The *NewSunX509* KeyManagerFactory
implementation has been available since Java 1.5, which is capable of doing
this, unlike the current default SunX509.
The second way requires less code changes and can be 100% backward compatible,
if the usage doesn't require the change.
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 #1*
> 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. *Proposed Improvement #2 (recommended)*
> Another way to support the single EKU certificates, if Flink can handle
> multiple certificates in one keystroke. This way the {{serverAuth}} EKU
> certificates, provided by a public CA and an internal one for {{clientAuth}}
> also delivered in the same keystone, so no change is required in the
> configuration options.
> The only thing that needs to be verified, if the used KeyManagerFactory is
> able to pick the right certificate when needed. The *NewSunX509*
> KeyManagerFactory implementation has been available since Java 1.5, which is
> capable of doing this, unlike the current default SunX509.
> The second way requires less code changes and can be 100% backward
> compatible, if the usage doesn't require the change.
> 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)
