[
https://issues.apache.org/jira/browse/IGNITE-29210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29210:
--------------------------------------
Description:
Let administrators replace node certificates and trust stores without
restarting nodes or closing established connections. {{control.sh --ssl
reload}} applies replacements; {{control.sh --ssl status}} reports the material
in use on every server and client node in the current topology. IGNITE-29211
and IGNITE-29212 reuse this mechanism for renewal and HTTP REST.
h3. Result and acceptance
* Cover discovery, communication, the client connector and binary REST.
Transports sharing a factory switch together; distinct factory instances remain
independent. New connections use replacement material, existing connections
remain usable, and communication reconnects reuse the registered context.
* Validate before publication: reject unsupported TLS settings, a context
already in use, invalid dates in any reported chain, or a known empty chain
map. Failure retains the working bundle. Manual reload does not require a later
expiry.
* Preserve permissive first initialization for certificate dates and missing
chains. Unknown metadata permits manual reload without date validation; status
distinguishes it from an empty chain map and reports only included X.509 chains.
* Report each node, factory, transport and reload outcome. Partial failures,
including selected nodes leaving before execution, fail the command while other
nodes are still processed. Require {{ADMIN_OPS}} for both commands and audit
reload attempts with their initiator.
* Direct {{init()}} calls must also be visible through node transports and
status.
h3. Operator and extension compatibility
Reload loads updated store contents; factory settings require a restart, and
application client stores are updated separately. Explicit {{trustManagers}}
remain in use. Reload does not prove peer trust or roll back a successful
replacement after a later handshake failure. See [rollout and
recovery|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#upgrading-certificates]
and the [command
reference|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/tools/control-script.adoc#reloading-certificates].
Registered node transports follow replacements through a shared forwarding
context. Code retaining a context from {{factory.create()}} must obtain it
again after {{init()}}.
Plain {{Factory<SSLContext>}} is called at registration and reload and must
return a fresh replacement context. Follow IGNITE-29209's subclass migration;
custom {{TcpDiscoverySpi}} subclasses using the removed protected
{{sslSockFactory}} or {{sslSrvSockFactory}} fields also require adaptation and
recompilation.
h3. Delivery
Depends on IGNITE-29209; open the PR after that API merges.
Local checks: 23 provider/reload/reconnect cases passed at {{4a7ce7c9}}; the
CLI case and Checkstyle passed at {{756e613f}}, with one existing JMX skip.
Commons and core are identical between those heads. This is not full CI.
was:
Let administrators replace node certificates and trust stores without
restarting nodes or closing established connections. {{control.sh --ssl
reload}} applies replacements; {{control.sh --ssl status}} reports the material
in use on every server and client node in the current topology. Automatic
renewal and HTTP REST reuse this mechanism in IGNITE-29211 and IGNITE-29212.
h3. Result and acceptance
* Cover discovery, communication, the client connector and binary REST.
Transports sharing the same factory object switch together; distinct factory
instances remain independent. New connections use accepted replacement material
and existing connections remain usable. Communication reconnects reuse the
registered context, including with a plain {{Factory<SSLContext>}}.
* Validate before publication: reject unsupported TLS settings, a context
already in use, invalid dates in any reported chain, or a known empty chain
map. Retain the working bundle on failure. Manual reload does not require a
later expiry.
* Preserve permissive first initialization for certificate dates and missing
chains. Unknown metadata allows manual reload but prevents date validation;
status must distinguish it from an empty chain map and report only included
X.509 chains.
* Report each node, factory, transport and reload outcome. A failure, including
a selected node leaving before execution, makes the command fail while other
nodes are still processed. Require {{ADMIN_OPS}} for both commands and audit
reload attempts with their initiator.
* Test mutual TLS and trust changes with real connections, shared/separate
factories, partial failures, permissions and direct {{init()}} calls visible
through node transports and status.
h3. Operator and extension compatibility
Reload applies changes to store contents. Factory settings require
configuration changes and a restart; application client stores must be updated
separately. Explicit {{trustManagers}} remain in use. Prepare peer trust first
and test new connections afterward: reload does not prove peer trust or roll
back a successful replacement because a later handshake fails. Follow [Reload
or
Restart|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#reload-or-restart],
[Upgrading
Certificates|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#upgrading-certificates]
and the [command
reference|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/tools/control-script.adoc#reloading-certificates].
Registered node transports follow replacements through their shared forwarding
context. Code that directly retains a context from {{factory.create()}} must
obtain it again after successful {{init()}}.
A plain {{Factory<SSLContext>}} is called at registration and reload and must
return a fresh context for replacement. Follow IGNITE-29209's subclass
migration. Custom {{TcpDiscoverySpi}} subclasses using the removed protected
{{sslSockFactory}} or {{sslSrvSockFactory}} fields must also be adapted and
recompiled.
h3. Delivery
Open the PR after IGNITE-29209 merges; review only this task's changes against
that accepted API.
All 23 provider/reload/reconnect tests passed at {{4a7ce7c9}}. The
generated-store CLI test passed at {{756e613f}}, with one existing JMX skip,
and Checkstyle passed. The commons and core source trees are identical between
those heads. These are local targeted checks, not full CI.
> 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
>
> Let administrators replace node certificates and trust stores without
> restarting nodes or closing established connections. {{control.sh --ssl
> reload}} applies replacements; {{control.sh --ssl status}} reports the
> material in use on every server and client node in the current topology.
> IGNITE-29211 and IGNITE-29212 reuse this mechanism for renewal and HTTP REST.
> h3. Result and acceptance
> * Cover discovery, communication, the client connector and binary REST.
> Transports sharing a factory switch together; distinct factory instances
> remain independent. New connections use replacement material, existing
> connections remain usable, and communication reconnects reuse the registered
> context.
> * Validate before publication: reject unsupported TLS settings, a context
> already in use, invalid dates in any reported chain, or a known empty chain
> map. Failure retains the working bundle. Manual reload does not require a
> later expiry.
> * Preserve permissive first initialization for certificate dates and missing
> chains. Unknown metadata permits manual reload without date validation;
> status distinguishes it from an empty chain map and reports only included
> X.509 chains.
> * Report each node, factory, transport and reload outcome. Partial failures,
> including selected nodes leaving before execution, fail the command while
> other nodes are still processed. Require {{ADMIN_OPS}} for both commands and
> audit reload attempts with their initiator.
> * Direct {{init()}} calls must also be visible through node transports and
> status.
> h3. Operator and extension compatibility
> Reload loads updated store contents; factory settings require a restart, and
> application client stores are updated separately. Explicit {{trustManagers}}
> remain in use. Reload does not prove peer trust or roll back a successful
> replacement after a later handshake failure. See [rollout and
> recovery|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#upgrading-certificates]
> and the [command
> reference|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/tools/control-script.adoc#reloading-certificates].
> Registered node transports follow replacements through a shared forwarding
> context. Code retaining a context from {{factory.create()}} must obtain it
> again after {{init()}}.
> Plain {{Factory<SSLContext>}} is called at registration and reload and must
> return a fresh replacement context. Follow IGNITE-29209's subclass migration;
> custom {{TcpDiscoverySpi}} subclasses using the removed protected
> {{sslSockFactory}} or {{sslSrvSockFactory}} fields also require adaptation
> and recompilation.
> h3. Delivery
> Depends on IGNITE-29209; open the PR after that API merges.
> Local checks: 23 provider/reload/reconnect cases passed at {{4a7ce7c9}}; the
> CLI case and Checkstyle passed at {{756e613f}}, with one existing JMX skip.
> Commons and core are identical between those heads. This is not full CI.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
