[
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 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.
was:
Allow administrators to replace node TLS certificates and trust stores without
restarting nodes. When an external system delivers certificates, let Ignite
load valid replacements automatically before the current chains expire.
Existing connections remain usable; peer trust must be prepared separately.
h3. Parts and consumers
# IGNITE-29208 preserves the peer address of wrapped SSL engines; [PR
#13750|https://github.com/apache/ignite/pull/13750] is merged.
# IGNITE-29209 keeps a factory-owned context and certificate snapshot from one
store read. A factory subclass can use protected {{init()}} to load a fresh
snapshot. Callers obtain its context with {{create()}}. A failed replacement
keeps the previous context in use. [PR
#13751|https://github.com/apache/ignite/pull/13751] covers this part.
# IGNITE-29210 adds reload/status for discovery, communication, the client
connector and binary REST, with validation, per-node results, permissions and
audit. Its forwarding context lets node transports follow replacements.
# IGNITE-29211 adds opt-in renewal, retries and monitoring; the external system
still issues and supplies certificates.
# IGNITE-29212 adds HTTP REST to reload/status and, together with IGNITE-29211,
automatic HTTPS renewal.
h3. Merge and integration order
Merge IGNITE-29209, then IGNITE-29210 ([PR
#13785|https://github.com/apache/ignite/pull/13785]). IGNITE-29211 ([PR
#13786|https://github.com/apache/ignite/pull/13786]) and IGNITE-29212 ([PR
#13787|https://github.com/apache/ignite/pull/13787]) may then merge in either
order. Include the [joint integration
commit|https://github.com/anton-vinogradov/ignite/commit/889a3fde5349850cc29428f0511bc51f42a6d599]
once in the PR that merges second, after both foundations are present.
h3. Completion
Each part includes tests and user/developer documentation. Verify the combined
solution with mutual TLS, trust changes, existing configurations and automatic
HTTPS renewal, preserving configured HTTP TLS parameters.
Factory subclasses require adaptation and recompilation under IGNITE-29209;
plain {{Factory<SSLContext>}} remains supported. Transport and Jetty migration
limits belong to their owning tasks. See [factory
migration|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#migrating-an-existing-factory]
and [certificate
rollout/recovery|https://github.com/anton-vinogradov/ignite/blob/ignite-29210/docs/_docs/security/ssl-tls.adoc#upgrading-certificates].
At {{f4a9191a}}, all 86 local tests in the combined SSL and HTTPS suites
passed, including automatic certificate renewal over HTTPS. Checkstyle passed.
Close the umbrella after all parts merge and combined validation passes.
> [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 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.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
