[
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.
* When a factory subclass replaces its material through protected {{init()}},
node transports and status must also see the replacement.
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 a successful reload.
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
Merge [PR #13785|https://github.com/apache/ignite/pull/13785] after the
IGNITE-29209 API ([PR #13751|https://github.com/apache/ignite/pull/13751]).
At {{dfe2f485}}, 37 targeted metadata, provider, reload and CLI tests passed.
The existing JMX variant was skipped. Checkstyle passed.
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. 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
Merge [PR #13785|https://github.com/apache/ignite/pull/13785] after the
IGNITE-29209 API ([PR #13751|https://github.com/apache/ignite/pull/13751]).
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.
> 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
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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.
> * When a factory subclass replaces its material through protected {{init()}},
> node transports and status must also see the replacement.
> 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 a successful reload.
> 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
> Merge [PR #13785|https://github.com/apache/ignite/pull/13785] after the
> IGNITE-29209 API ([PR #13751|https://github.com/apache/ignite/pull/13751]).
> At {{dfe2f485}}, 37 targeted metadata, provider, reload and CLI tests passed.
> The existing JMX variant was skipped. Checkstyle passed.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
