[
https://issues.apache.org/jira/browse/IGNITE-28867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130450#comment-18130450
]
Anton Vinogradov commented on IGNITE-28867:
-------------------------------------------
[Ignite PR Checker|https://ignite-pr-checker.is-a.dev/?pr=13335] verdict for PR
13335 · RunAll build [9432959|https://ci2.ignite.apache.org/build/9432959] ·
tested
[9b539b4|https://github.com/apache/ignite/pull/13335/commits/9b539b482f3912dc5e6e2e7b6c6905b015c7a7d3]
· 149 suites ran, 0 reused
(!) *This run doesn't cover the PR fully:*
- mixed run — ZooKeeper (Discovery) 3 re-ran on 04c6db2, the rest of the RunAll
ran on 9b539b4; only a RunAll of the PR's head can prove it clean
Everything below is what it did manage to say.
(?) *No blockers found — but the run above can't prove the PR is clean.* 21
failing tests are not blamed on this PR. Re-run after you handle what is listed
above.
_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]._
_The PR is now at {{04c6db2}}._
♻️ Settled after 1 auto re-run wave: #1 — 1 suite that failed mid-run.
> 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 50m
> 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
(v10.3.26#10030026)
