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

Anton Vinogradov updated IGNITE-28867:
--------------------------------------
    Release Note: Added TLS certificate reload and optional automatic renewal 
for running nodes, including factory-managed HTTPS, without closing established 
connections.  (was: Added control.sh --ssl reload and control.sh --ssl status 
to replace the TLS certificates of running nodes without a restart, and 
optional automatic certificate renewal.)
     Description: 
Rotate TLS certificates and trust on running nodes without closing established 
connections. An external source supplies the material; Ignite loads it on 
command or, when enabled, before expiry.

h3. Deliverables

# IGNITE-29208: preserve peer information on wrapped SSL engines. Already 
merged in [PR #13750|https://github.com/apache/ignite/pull/13750].
# IGNITE-29209: let a factory subclass reload its context while preserving 
existing cached creation behavior.
# IGNITE-29256: make new connections of the four TCP transports use the 
factory's current context.
# IGNITE-29210: provide authorized manual reload for the four TCP transports, 
with per-node results and an outcome log.
# IGNITE-29211: add automatic renewal, necessary expiry checks, retries and 
failure monitoring.
# IGNITE-29212: add factory-managed HTTPS, include it in manual reload and 
renewal; HTTPS configured in Jetty XML stays unchanged and outside reload.

h3. Order and completeness

Merge in this order: IGNITE-29209, IGNITE-29256, IGNITE-29210, IGNITE-29211, 
IGNITE-29212. IGNITE-29212 includes the HTTPS renewal test and the combined 
documentation. Refresh dependent PRs after each prerequisite merges; their 
diffs must contain only their remaining changes.

Each ticket defines its required results and acceptance checks. Its PR explains 
the implementation and records verification. Confirm key/trust rotation on all 
supported transports, automatic renewal, established connections, failure 
recovery and monitoring.

Certificate issuance, live node reconfiguration, a separate status command, 
certificate inventory and universal support for arbitrary factories are outside 
this scope. Local loading success alone does not establish peer trust.


  was:
Rotate TLS certificates and trust on running nodes without closing established 
connections. An external source supplies the material; Ignite loads it on 
command or, when enabled, before expiry.

h3. Deliverables

# IGNITE-29208: preserve peer information on wrapped SSL engines. Already 
merged in [PR #13750|https://github.com/apache/ignite/pull/13750].
# IGNITE-29209: let a factory explicitly reload its material while preserving 
existing cached creation behavior.
# IGNITE-29210: provide authorized manual reload for the four TCP transports, 
per-node results and audit.
# IGNITE-29211: add automatic renewal, necessary expiry checks, retries and 
failure monitoring.
# IGNITE-29212: extend the same operation to HTTPS, preserving existing Jetty 
TLS behavior.

h3. Order and completeness

Merge IGNITE-29209 before IGNITE-29210. Renewal and HTTP can follow in either 
order. The ticket merged second includes the combined HTTPS renewal test and 
documentation. Refresh dependent PRs after each prerequisite merges; their 
diffs must contain only their remaining changes.

Each ticket defines its required results and acceptance checks. Its PR explains 
the implementation and records verification. Confirm key/trust rotation on all 
supported transports, automatic renewal, established connections, failure 
recovery and monitoring.

Certificate issuance, live node reconfiguration, a separate status command, 
certificate inventory and universal support for arbitrary factories are outside 
this scope. Local loading success alone does not establish peer trust.


> [Umbrella] TLS certificate reload and automatic renewal
> -------------------------------------------------------
>
>                 Key: IGNITE-28867
>                 URL: https://issues.apache.org/jira/browse/IGNITE-28867
>             Project: Ignite
>          Issue Type: Task
>            Reporter: Mikhail Petrov
>            Assignee: Anton Vinogradov
>            Priority: Major
>              Labels: ise
>             Fix For: 2.19
>
>          Time Spent: 7h
>  Remaining Estimate: 0h
>
> Rotate TLS certificates and trust on running nodes without closing 
> established connections. An external source supplies the material; Ignite 
> loads it on command or, when enabled, before expiry.
> h3. Deliverables
> # IGNITE-29208: preserve peer information on wrapped SSL engines. Already 
> merged in [PR #13750|https://github.com/apache/ignite/pull/13750].
> # IGNITE-29209: let a factory subclass reload its context while preserving 
> existing cached creation behavior.
> # IGNITE-29256: make new connections of the four TCP transports use the 
> factory's current context.
> # IGNITE-29210: provide authorized manual reload for the four TCP transports, 
> with per-node results and an outcome log.
> # IGNITE-29211: add automatic renewal, necessary expiry checks, retries and 
> failure monitoring.
> # IGNITE-29212: add factory-managed HTTPS, include it in manual reload and 
> renewal; HTTPS configured in Jetty XML stays unchanged and outside reload.
> h3. Order and completeness
> Merge in this order: IGNITE-29209, IGNITE-29256, IGNITE-29210, IGNITE-29211, 
> IGNITE-29212. IGNITE-29212 includes the HTTPS renewal test and the combined 
> documentation. Refresh dependent PRs after each prerequisite merges; their 
> diffs must contain only their remaining changes.
> Each ticket defines its required results and acceptance checks. Its PR 
> explains the implementation and records verification. Confirm key/trust 
> rotation on all supported transports, automatic renewal, established 
> connections, failure recovery and monitoring.
> Certificate issuance, live node reconfiguration, a separate status command, 
> certificate inventory and universal support for arbitrary factories are 
> outside this scope. Local loading success alone does not establish peer trust.



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

Reply via email to