[
https://issues.apache.org/jira/browse/IGNITE-28867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-28867:
--------------------------------------
Description:
Administrators can replace TLS certificates and trust on running nodes. An
external issuer delivers the certificates. Ignite can also pick up renewed
material before the earliest chain expires. Existing connections stay open.
h3. Scope and merge order
# IGNITE-29208 preserves the peer address when creating a wrapped SSL engine.
[PR #13750|https://github.com/apache/ignite/pull/13750] is merged.
# IGNITE-29209 loads a context and its certificate chains together.
IGNITE-29210 uses this snapshot for the administrator's reload and status
commands.
# IGNITE-29211 schedules renewal and retries. IGNITE-29212 adds HTTP REST to
the node's reload and status commands. These two parts can merge in either
order after IGNITE-29210.
After each prerequisite is squash-merged, update all dependent branches and
verify that each PR diff against master contains only its own remaining
changes. Once both renewal and HTTP changes are present, apply the [HTTPS
renewal test and
documentation|https://github.com/anton-vinogradov/ignite/commit/b4f505eeea2a448b67e2234b5bb3368768646e25]
once in the PR merged second.
h3. Completion
Verify rotation over new mutual TLS and HTTPS connections, continued use of
existing connections, and recovery after an invalid replacement. Each PR
records its validation. The [rollout
guide|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#upgrading-certificates]
covers the order in which operators must update peer trust and certificates.
was:
Administrators can replace TLS certificates and trust on running nodes. An
external issuer delivers the certificates. Ignite can also pick up renewed
material before the earliest chain expires. Existing connections stay open.
h3. Scope and merge order
# IGNITE-29208 preserves the peer address when creating a wrapped SSL engine.
[PR #13750|https://github.com/apache/ignite/pull/13750] is merged.
# IGNITE-29209 loads a context and its certificate chains together.
IGNITE-29210 uses this snapshot for the administrator's reload and status
commands.
# IGNITE-29211 schedules renewal and retries. IGNITE-29212 adds HTTP REST to
the node's reload and status commands. These two parts can merge in either
order after IGNITE-29210.
After a prerequisite is squash-merged, merge the updated master into the
dependent branch and check the PR diff against master. It should contain only
the remaining changes. Once both renewal and HTTP changes are present, apply
the [HTTPS renewal test and
documentation|https://github.com/anton-vinogradov/ignite/commit/d554ba23f34e7227f6c998284934a3e1af426d2b]
once in the PR merged second.
h3. Completion
Verify rotation over new mutual TLS and HTTPS connections, continued use of
existing connections, and recovery after an invalid replacement. Each PR
records its validation. The [rollout
guide|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#upgrading-certificates]
covers the order in which operators must update peer trust and certificates.
> [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
>
> Administrators can replace TLS certificates and trust on running nodes. An
> external issuer delivers the certificates. Ignite can also pick up renewed
> material before the earliest chain expires. Existing connections stay open.
> h3. Scope and merge order
> # IGNITE-29208 preserves the peer address when creating a wrapped SSL engine.
> [PR #13750|https://github.com/apache/ignite/pull/13750] is merged.
> # IGNITE-29209 loads a context and its certificate chains together.
> IGNITE-29210 uses this snapshot for the administrator's reload and status
> commands.
> # IGNITE-29211 schedules renewal and retries. IGNITE-29212 adds HTTP REST to
> the node's reload and status commands. These two parts can merge in either
> order after IGNITE-29210.
> After each prerequisite is squash-merged, update all dependent branches and
> verify that each PR diff against master contains only its own remaining
> changes. Once both renewal and HTTP changes are present, apply the [HTTPS
> renewal test and
> documentation|https://github.com/anton-vinogradov/ignite/commit/b4f505eeea2a448b67e2234b5bb3368768646e25]
> once in the PR merged second.
> h3. Completion
> Verify rotation over new mutual TLS and HTTPS connections, continued use of
> existing connections, and recovery after an invalid replacement. Each PR
> records its validation. The [rollout
> guide|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#upgrading-certificates]
> covers the order in which operators must update peer trust and certificates.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
