[
https://issues.apache.org/jira/browse/IGNITE-28867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127650#comment-18127650
]
Anton Vinogradov commented on IGNITE-28867:
-------------------------------------------
[Ignite PR Checker|https://ignite-pr-checker.is-a.dev/?pr=13335] verdict for PR
13335 · RunAll build [9414597|https://ci2.ignite.apache.org/build/9414597] ·
tested
[975799d|https://github.com/apache/ignite/pull/13335/commits/975799d7791fbbffddf9df2fe66bc548c26f635b]
· 147 suites ran, 0 reused
(x) *1 blocker(s) in 1 suite(s):*
- JDBC Driver · {{JdbcThinConnectionSSLTest.testInvalidCustomCipher}} — failed
3 of 3 runs of this code ·
[TC|https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_JdbcDriver/9414778?buildTab=tests&expandedTest=build%3A%28id%3A9414778%29%2Cid%3A2000000454#testNameId9820503558489800752]
_What each label means and what to do: [verdict
glossary|https://github.com/anton-vinogradov/ignite-pr-checker/blob/main/docs/features.md#verdict-glossary]._
♻️ Settled after 2 auto re-run wave(s): #1 — 6 suites that failed mid-run; #2 —
1 blocker suite(s).
> Add control.sh --ssl commands for TLS certificate hot redeployment
> ------------------------------------------------------------------
>
> Key: IGNITE-28867
> URL: https://issues.apache.org/jira/browse/IGNITE-28867
> Project: Ignite
> Issue Type: Task
> Reporter: Mikhail Petrov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ise
> Fix For: 2.19
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Currently, Ignite node TLS certificates are loaded only once during node
> startup and then used to establish secure connections between `node to node`,
> `node to thin client`. As a result, updating a certificate requires
> restarting the Ignite node, causing unnecessary downtime and requiring
> additional administrative effort.
> We need to implement hot redeployment of TLS certificates, allowing the
> Ignite node to reload the certificates at runtime without requiring a node
> restart. Existing TLS sessions should remain unaffected, while all new TLS
> handshakes should use the updated credentials.
> Basic Steps
> 1. Introduce a mechanism to trigger certificate reloading (for example,
> through `control.sh`).
> 2. Create a new `SslContext` instance by invoking `SslContextFactory`.
> 3. Replace the active `SslContext` used for TLS connection establishment. All
> newly established connections must use the updated certificates, while
> existing connections will continue to operate without interruption.
> h2. Design
> The pull request describes the design in full:
> https://github.com/apache/ignite/pull/13335. In short:
> *Commands.* {{control.sh --ssl reload}} is run against any node and reaches
> every node of the cluster, servers and clients. Each node asks its own SSL
> context factories for new contexts, so the command carries no certificate and
> no path. {{control.sh --ssl status}} reports the certificate every node
> serves and the result of its last reload.
> *Discovery.* The listening socket is now a plain {{ServerSocket}}, and every
> accepted connection is wrapped with the context current at that moment. An
> {{SSLServerSocket}} captures the context at bind time, which would have left
> discovery reloadable for outbound connections only.
> *Automatic renewal.* Optional and off by default: with {{renewalEnabled}} set
> on the SSL context factory, a node reads its stores again when
> {{renewBeforeFraction}} of the certificate lifetime is left, with the same
> checks.
> *Check before applying.* A rebuilt context goes in use only if every
> certificate of its chain is valid now, and it presents a certificate whenever
> the context in use does. If the factory serves discovery or communication,
> the node's own trust store must also accept the new certificate; the node
> checks this with a TLS handshake in memory and asks no other node. Otherwise
> the node keeps its current certificates, and the command reports the reason
> for that node.
> h2. Why the context is replaced rather than the key managers
> The alternative is to keep one {{SSLContext}} and swap the delegates inside
> {{X509ExtendedKeyManager}}/{{X509ExtendedTrustManager}}. Elasticsearch had
> exactly that and removed it in elastic/elasticsearch#30509 for FIPS 140-2,
> where only SunJSSE managers may be used; Jetty and Kafka also rebuild the
> context. Swapping managers additionally keeps the session cache and ticket
> keys of the old context, so a resumed session is still served the old
> certificate and trust cannot be revoked by a reload.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
