[ 
https://issues.apache.org/jira/browse/IGNITE-29210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Vinogradov updated IGNITE-29210:
--------------------------------------
    Description: 
Allow administrators to reload TLS certificates and trust material on running 
server and thick-client nodes with {{control.sh --ssl reload}}, without 
restarting nodes or closing established connections.

h3. Behavior

* Cover TCP discovery, communication, the client connector and binary REST. 
Reload each shared factory once per node, using {{init()}} from IGNITE-29209 
and the existing context cache.
* New connections use the replacement after successful loading. During loading, 
or if it fails, they continue using the previous context. Preserve existing TLS 
settings and client authentication.
* Require {{ADMIN_OPS}} and log the initiator and outcome. Report results by 
node and transport; continue after individual failures and return an error for 
failed, unsupported or unavailable targets. Nodes without TLS need no action.

h3. Scope

Support {{SslContextFactory}} and subclasses using the base context lifecycle, 
including custom key and trust loaders. Other factories retain their current 
behavior; the command reports that reload is unsupported. Reread the configured 
sources; changing node configuration still requires a restart.

Keep existing loading checks and startup behavior. Separate {{--ssl status}}, 
certificate metadata, additional certificate-date checks, automatic renewal and 
HTTP REST are outside this ticket.

h3. Acceptance

Test certificate and trust replacement on all four transports, old and new 
connections, failed loading, shared factories, custom loading hooks, partial 
failures and permissions.

Document trust preparation and verification with a new TLS connection: 
successful local loading does not prove that peers accept the certificate. If 
verification fails, restore the previous material and reload.

Depends on IGNITE-29209. [PR 
#13785|https://github.com/apache/ignite/pull/13785].

  was:
Administrators can rotate TLS certificates and trust stores and check the 
result on every server and client node without restarting any node. The 
commands cover discovery, communication, the client connector and binary REST. 
Both require {{ADMIN_OPS}}.

h3. Result

* {{control.sh --ssl reload}} reloads each factory once per node. Transports 
sharing it use the new certificates for new connections. Existing connections 
stay open. The command records the initiator and continues with other factories 
and nodes after a failure.
* Startup and reload require a context that can create TLS engines and stream 
sockets. At first registration a node can start with a warning if the factory 
reports no X.509 chains or a certificate outside its validity period. Reload 
rejects the context already in use, a store reporting no X.509 chains and 
chains containing expired or not-yet-valid certificates. A failed reload keeps 
the previous context. Calling {{init()}} on the same factory at restart uses 
the reload checks.
* {{control.sh --ssl status}} shows transports and aliases for each factory. It 
distinguishes a store without X.509 chains from a factory that cannot report 
its chains.

h3. Compatibility

Give each node its own {{AbstractSslContextFactory}} instance. Nodes sharing 
one instance switch certificates together and report the same reload result. 
Ignite calls a plain {{Factory<SSLContext>}} when its first transport registers 
and again on reload. New outgoing communication connections reuse that context. 
Previously, each new outgoing communication connection called the factory. On 
reload it must return a fresh context and supplies no chains for date checks. 
Update and recompile custom discovery SPI subclasses that used the removed 
protected fields {{sslSockFactory}} and {{sslSrvSockFactory}}. Configure peer 
trust before rotation and verify it with a new connection. [Rollout and 
recovery|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#upgrading-certificates].

Builds on IGNITE-29209. Code and validation are in [PR 
#13785|https://github.com/apache/ignite/pull/13785].



> 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: 1h 10m
>  Remaining Estimate: 0h
>
> Allow administrators to reload TLS certificates and trust material on running 
> server and thick-client nodes with {{control.sh --ssl reload}}, without 
> restarting nodes or closing established connections.
> h3. Behavior
> * Cover TCP discovery, communication, the client connector and binary REST. 
> Reload each shared factory once per node, using {{init()}} from IGNITE-29209 
> and the existing context cache.
> * New connections use the replacement after successful loading. During 
> loading, or if it fails, they continue using the previous context. Preserve 
> existing TLS settings and client authentication.
> * Require {{ADMIN_OPS}} and log the initiator and outcome. Report results by 
> node and transport; continue after individual failures and return an error 
> for failed, unsupported or unavailable targets. Nodes without TLS need no 
> action.
> h3. Scope
> Support {{SslContextFactory}} and subclasses using the base context 
> lifecycle, including custom key and trust loaders. Other factories retain 
> their current behavior; the command reports that reload is unsupported. 
> Reread the configured sources; changing node configuration still requires a 
> restart.
> Keep existing loading checks and startup behavior. Separate {{--ssl status}}, 
> certificate metadata, additional certificate-date checks, automatic renewal 
> and HTTP REST are outside this ticket.
> h3. Acceptance
> Test certificate and trust replacement on all four transports, old and new 
> connections, failed loading, shared factories, custom loading hooks, partial 
> failures and permissions.
> Document trust preparation and verification with a new TLS connection: 
> successful local loading does not prove that peers accept the certificate. If 
> verification fails, restore the previous material and reload.
> Depends on IGNITE-29209. [PR 
> #13785|https://github.com/apache/ignite/pull/13785].



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

Reply via email to