[
https://issues.apache.org/jira/browse/IGNITE-29210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29210:
--------------------------------------
Description:
Administrators need to replace node certificates and trust stores without
restarting nodes or closing existing connections. Add {{control.sh --ssl
reload}} to apply replacements and {{control.sh --ssl status}} to check what
each server and client node in the current topology has loaded.
h3. How reload works
Discovery, communication, the client connector and binary REST use one managed
context per factory instance. Sharing a factory therefore updates those
transports together; distinct instances remain independent even if they compare
equal. New connections use the replacement context and existing connections
stay open.
Use IGNITE-29209's fresh-context and metadata API to check a replacement before
installing it. Reject unsupported TLS settings, known invalid certificate
dates, explicitly missing private keys and a factory returning the context
already in use. Keep the previous context on failure. Unknown metadata alone
must not prevent manual reload, but it means certificate dates cannot be
checked. Reload does not probe connections or establish whether peers trust the
replacement; the administrator must verify that separately.
Report each factory's result and transports on each node. Status shows loaded
metadata and reload outcomes, including unavailable metadata and invalid
certificates. If any selected node fails, including one that leaves before its
job is assigned, return an error while processing the remaining nodes. Require
ADMIN_OPS for both commands and log each factory reload attempt with its
initiator.
h3. Acceptance and documentation
Cover all four transports, mutual TLS and trust changes, new and existing
connections, shared and separate factories, custom factories, partial failures,
departing nodes, permissions, audit and command parsing. Include the shared
certificate generator and its test-only Bouncy Castle dependency.
Explain how to prepare peer trust, replace files, verify new connections and
recover from a failed rollout. Distinguish changes to file contents, which
reload applies, from factory settings that require a restart. Application
client stores must be updated separately. Document fresh creation, optional
metadata and serialized calls in the custom-factory reference.
h3. Dependencies and remaining work
Implementation, tests and documentation are prepared on {{ignite-29210}}. Open
its PR after IGNITE-29209 is merged and run CI on the updated branch. This task
completes manual reload and status. IGNITE-29211 uses the same replacement
mechanism for scheduled renewal; IGNITE-29212 extends it to HTTP REST. Both
remain separate tasks.
h3. Compatibility
The protected TcpDiscoverySpi.sslSockFactory and
TcpDiscoverySpi.sslSrvSockFactory fields are removed. This is a source and
binary compatibility change for custom TcpDiscoverySpi subclasses that access
these fields; adapt those subclasses before upgrading.
Protocol and cipher-suite names configured through AbstractSslContextFactory
must be supported by the running JVM. Unsupported names now fail node startup
for every managed TCP transport: discovery, communication, the client connector
and binary REST. Some transports previously detected these errors only when
opening a connection.
For a plain Factory<SSLContext>, the node calls create() when registering the
factory at startup and once per requested reload. Transports configured with
the same factory object share its context. Communication no longer calls
create() for each outgoing connection, so custom factories must not rely on
those calls to refresh certificates. To support reload, each subsequent call
must return a fresh SSLContext.
was:
Allow administrators to replace node certificates and trust stores without
restarting nodes. Add {{control.sh --ssl reload}} and {{--ssl status}} for
server and client nodes in the current topology.
h3. Required behavior
* Keep one managed context per factory instance. Discovery, communication, the
client connector and binary REST must use it. Transports sharing the same
factory reload together. Distinct instances remain independent even if they
compare equal.
* New connections use the replacement context. Existing connections stay open.
Build and validate the replacement before installing it, and retain the
previous context on failure.
* Reject unsupported TLS settings, known invalid certificate dates, explicitly
missing private keys and a factory that returns the context already in use.
Unknown certificate metadata alone must not prevent manual reload. Do not probe
TLS connections or claim to verify peer trust.
* Report one result per factory on each node, listing its transports. Return an
error if any selected node fails, including a node that leaves before its job
is assigned. Continue processing the other nodes.
* Status reports loaded certificate metadata and reload results, including
unavailable metadata and invalid loaded certificates.
* Require ADMIN_OPS for both commands. Log each factory reload attempt with its
initiator.
h3. Tests and documentation
Cover all four transports, mutual TLS, trust-store changes, new and existing
connections, shared and separate factories, custom factories, partial failures,
nodes leaving the topology, permissions, audit output and command parsing.
Include the shared test certificate generator and Bouncy Castle as a test
dependency.
Explain certificate replacement, verification and recovery in the administrator
guide. Document fresh context creation, optional metadata and serialized
factory calls in the custom-factory reference.
h3. Dependencies and remaining work
The branch {{ignite-29210}} is prepared. Open its PR after IGNITE-29209 is
merged, then run CI on the updated branch.
This task delivers manual reload and status. Automatic renewal is tracked in
IGNITE-29211 and HTTP REST integration in IGNITE-29212.
h3. Compatibility
The protected TcpDiscoverySpi.sslSockFactory and
TcpDiscoverySpi.sslSrvSockFactory fields are removed. This is a source and
binary compatibility change for custom TcpDiscoverySpi subclasses that access
these fields; adapt those subclasses before upgrading.
Protocol and cipher-suite names configured through AbstractSslContextFactory
must be supported by the running JVM. Unsupported names now fail node startup
for every managed TCP transport: discovery, communication, the client connector
and binary REST. Some transports previously detected these errors only when
opening a connection.
For a plain Factory<SSLContext>, the node calls create() when registering the
factory at startup and once per requested reload. Transports configured with
the same factory object share its context. Communication no longer calls
create() for each outgoing connection, so custom factories must not rely on
those calls to refresh certificates. To support reload, each subsequent call
must return a fresh SSLContext.
> Reload TLS certificates on running nodes
> ----------------------------------------
>
> Key: IGNITE-29210
> URL: https://issues.apache.org/jira/browse/IGNITE-29210
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ise
>
> Administrators need to replace node certificates and trust stores without
> restarting nodes or closing existing connections. Add {{control.sh --ssl
> reload}} to apply replacements and {{control.sh --ssl status}} to check what
> each server and client node in the current topology has loaded.
> h3. How reload works
> Discovery, communication, the client connector and binary REST use one
> managed context per factory instance. Sharing a factory therefore updates
> those transports together; distinct instances remain independent even if they
> compare equal. New connections use the replacement context and existing
> connections stay open.
> Use IGNITE-29209's fresh-context and metadata API to check a replacement
> before installing it. Reject unsupported TLS settings, known invalid
> certificate dates, explicitly missing private keys and a factory returning
> the context already in use. Keep the previous context on failure. Unknown
> metadata alone must not prevent manual reload, but it means certificate dates
> cannot be checked. Reload does not probe connections or establish whether
> peers trust the replacement; the administrator must verify that separately.
> Report each factory's result and transports on each node. Status shows loaded
> metadata and reload outcomes, including unavailable metadata and invalid
> certificates. If any selected node fails, including one that leaves before
> its job is assigned, return an error while processing the remaining nodes.
> Require ADMIN_OPS for both commands and log each factory reload attempt with
> its initiator.
> h3. Acceptance and documentation
> Cover all four transports, mutual TLS and trust changes, new and existing
> connections, shared and separate factories, custom factories, partial
> failures, departing nodes, permissions, audit and command parsing. Include
> the shared certificate generator and its test-only Bouncy Castle dependency.
> Explain how to prepare peer trust, replace files, verify new connections and
> recover from a failed rollout. Distinguish changes to file contents, which
> reload applies, from factory settings that require a restart. Application
> client stores must be updated separately. Document fresh creation, optional
> metadata and serialized calls in the custom-factory reference.
> h3. Dependencies and remaining work
> Implementation, tests and documentation are prepared on {{ignite-29210}}.
> Open its PR after IGNITE-29209 is merged and run CI on the updated branch.
> This task completes manual reload and status. IGNITE-29211 uses the same
> replacement mechanism for scheduled renewal; IGNITE-29212 extends it to HTTP
> REST. Both remain separate tasks.
> h3. Compatibility
> The protected TcpDiscoverySpi.sslSockFactory and
> TcpDiscoverySpi.sslSrvSockFactory fields are removed. This is a source and
> binary compatibility change for custom TcpDiscoverySpi subclasses that access
> these fields; adapt those subclasses before upgrading.
> Protocol and cipher-suite names configured through AbstractSslContextFactory
> must be supported by the running JVM. Unsupported names now fail node startup
> for every managed TCP transport: discovery, communication, the client
> connector and binary REST. Some transports previously detected these errors
> only when opening a connection.
> For a plain Factory<SSLContext>, the node calls create() when registering the
> factory at startup and once per requested reload. Transports configured with
> the same factory object share its context. Communication no longer calls
> create() for each outgoing connection, so custom factories must not rely on
> those calls to refresh certificates. To support reload, each subsequent call
> must return a fresh SSLContext.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
