[
https://issues.apache.org/jira/browse/FLINK-40329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120141#comment-18120141
]
József Kuti commented on FLINK-40329:
-------------------------------------
When *JDK* is used for SslProvider, then Flink is using
*KeyManagerFactory.getDefaultAlgorithm()* to obtain the keyManagerFactory Type
which manages our JKS keystores.
By default *KeyManagerFactory.getDefaultAlgorithm()* returns "SunX509"
algorithm - type: sun.security.ssl.SunX509KeyManagerImpl - which does not
checks ExtendedKeyUsages (clientAuth / serverAuth) Extension in the
PrivateKeyEntries at all. This is the current state - the issue we have here.
See: sun.security.ssl.SunJSSE#doRegister for details
*NewSunX509* KeyManagerFactory algorithm - type:
sun.security.ssl.X509KeyManagerImpl, alias: *PKIX* - is already checking the
ExtendedKeyUsages fields in our PrivateKeyEntries - using this could solve our
issue here.
Luckily we can override the returned Type of
*KeyManagerFactory.getDefaultAlgorithm()* method by:
# creating a custom java.security where we override the
*ssl.KeyManagerFactory.algorithm* to *NewSunX509* - this is the only change
required for fixing this issue
## eg.: YOUR_PATH/custom.java.security which has
*ssl.KeyManagerFactory.algorithm=NewSunX509* set
# distribute this YOUR_PATH/custom.java.security on all the flink nodes
# update your *env.java.opts.-s* in your *flink-conf.yaml* - jobmanger,
taskmanager or all if you need this everywhere.
## eg.: *env.java.opts.all:
-Djava.security.properties=YOUR_PATH/custom.java.security*
### this way your custom security properties will be loaded from your custom
java.security file for flink java processes
## you can add *-Djava.security.debug=properties* to the the java opts *to
verify* you setup after flink job or history server is started
### during java startup you will see these stdout log lines:
properties: Initial security property:
ssl.KeyManagerFactory.algorithm=NewSunX509
I tested this approach in our environments and just worked fine.
No codechange - but small reconfig is required to update the used
keyManagerFactory in your flink java processes.
> 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)
