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

Anton Vinogradov updated IGNITE-29210:
--------------------------------------
    Description: 
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 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].

  was:
Administrators can reload node certificates and trust stores and inspect the 
result without restarting the cluster. The commands cover discovery, 
communication, the client connector and binary REST on every selected server 
and client node.

h3. Result

* {{control.sh --ssl reload}} updates each distinct registered factory once per 
node. Transports that share it use the replacement for new connections. 
Existing connections stay open. A rejected replacement keeps the previous 
context in service.
* Reload requires a fresh context, TLS engines and stream sockets. It checks 
validity dates on all reported chains and rejects a known empty chain map. 
First initialization permits expired certificates and keyless stores. A 
subclass that calls {{init()}} again on the same factory at restart gets the 
reload checks. A plain {{Factory<SSLContext>}} supplies no metadata, so reload 
can accept its new context without a date check.
* {{control.sh --ssl status}} identifies the transports and key aliases for 
each factory and distinguishes an empty store from unavailable metadata. Both 
commands require {{ADMIN_OPS}}. Reload records the initiator and reports any 
failed node or factory while processing the others.

h3. Compatibility

A plain factory is called when its first transport registers and on reload. It 
must return a fresh context to rotate material. Custom discovery SPI subclasses 
using the removed protected socket-factory fields need adaptation. Configure 
peer trust before rotating keys and check it with a new connection. See the 
[rollout and recovery 
guide|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#upgrading-certificates].

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


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



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

Reply via email to