[ 
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. 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.
* 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 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].

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. Final head: {{c4247675}}. Local validation in the combined 
integration {{ed06380c}}: 86 targeted SSL tests passed, two existing JMX 
variants were skipped, and Checkstyle passed. This is local combined 
validation, not full CI.


  was:
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 
forwarding 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.

{{AbstractSslContextFactory}} holds the accepted {{SslBundle}} from 
IGNITE-29209. Transports obtain its forwarding context through {{create()}}; 
reload calls {{init()}}, which validates and replaces the context and metadata 
together. The node registry records the original factory by object identity and 
the transports using it. Its provider delegates to the factory instead of 
storing another current bundle or reload outcome.

A plain {{Factory<SSLContext>}} remains supported: the provider wraps it in an 
adapter whose fresh-loading hook calls the original {{create()}} and reports 
unknown metadata. Custom factories follow the migration contract in 
IGNITE-29209.

Validate the replacement bundle before installing it. Reject unsupported TLS 
settings, an invalid date in any supplied certificate chain, a known empty 
chain map, or a factory returning the context already in use. Keep the previous 
bundle on failure.

The first initialization remains permissive for certificate dates and missing 
chains; those two checks apply to subsequent {{init()}} calls. Unsupported TLS 
settings are rejected at first initialization too. Manual reload does not 
require the new certificates to expire later than the current ones.

{{KeyMaterial}} omits entries without a nonempty X.509 chain, so those entries 
are not validated or reported. A mixed store is not rejected merely because 
other entries were skipped. If no chains remain, instruct the administrator to 
configure a key entry with a nonempty X.509 chain before retrying.

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 reports the 
included aliases and chains and the factory's reload outcome, including an 
empty chain map, 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. Verify that calling 
{{init()}} directly on a registered factory updates the material and outcome 
visible through its provider. Verify that reload rejects a known empty chain 
map but accepts valid included chains alongside omitted entries, and that 
status reports only included chains. Extend {{TestCertificateAuthority}} from 
IGNITE-29209 so tests can set validity dates and build trust stores with 
several certificate authorities.

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 the fresh-loading hook, 
optional metadata and factory-owned initialization in the custom-factory 
reference. {{init()}} serializes replacement attempts on the same factory 
instance, including calls from application code. Configure the factory before 
use; a custom loading hook must not mutate material already in use. Calls made 
directly to the public fresh-loading hook are outside this initialization lock.

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

Nodes use {{create()}} for the stable context and {{init()}} for replacement on 
{{AbstractSslContextFactory}} implementations. The factory migration in 
IGNITE-29209 makes {{create()}} final: move store loading to 
{{loadKeyMaterial()}}, remove custom context caching and let the factory retain 
the accepted bundle.

For custom key managers, override {{createSslBundle()}} to initialize a fresh 
context, configure its trust and TLS settings, and return matching certificate 
metadata. To decorate an already built context, call 
{{super.createSslBundle()}} and retain its certificate chains in the returned 
bundle.

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. As established in IGNITE-29209, 
communication does not call 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
>
> 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.
> * 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 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].
> 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. Final head: {{c4247675}}. Local validation in the 
> combined integration {{ed06380c}}: 86 targeted SSL tests passed, two existing 
> JMX variants were skipped, and Checkstyle passed. This is local combined 
> validation, not full CI.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to