[
https://issues.apache.org/jira/browse/IGNITE-28867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-28867:
--------------------------------------
Description:
Allow administrators to replace TLS certificates and trust stores without
restarting nodes. When an external system supplies new certificates, allow
Ignite to load them automatically before the current chain expires.
h3. What each part provides and what uses it
# IGNITE-29208 preserves the peer address when SSLContextWrapper creates an
engine. This independently fixes existing addressed client engines. [PR
#13750|https://github.com/apache/ignite/pull/13750] is merged.
# IGNITE-29209 builds a fresh SslBundle from one loaded KeyMaterial, containing
the context and certificate chains for every private-key alias. IGNITE-29210
uses the chains to check dates and report status, and an empty map to reject a
replacement with no private key. IGNITE-29211 uses the earliest expiry across
all chains to schedule renewal. SSLContextWrapper handles TLS parameters only.
[PR #13751|https://github.com/apache/ignite/pull/13751] is open.
# IGNITE-29210 owns the current bundle for each factory and provides manual
reload and status for discovery, communication, the client connector and binary
REST. It validates and replaces the context and metadata together, keeping
transports sharing a factory on the same certificates. IGNITE-29211 reuses this
replacement mechanism for scheduled attempts; IGNITE-29212 connects HTTP REST
to it.
# IGNITE-29211 adds scheduling, retries and the ssl.ConsecutiveRenewalFailures
metric. It requests a fresh bundle and uses the reload mechanism to install it
only when every chain is valid and the minimum expiry across all chains
advances. The certificate source remains responsible for supplying replacements.
# IGNITE-29212 adds httpSslFactory so Jetty HTTP REST can use managed contexts.
This makes HTTPS certificates available to reload and status, and to automatic
renewal once IGNITE-29211 is present.
The factory API change is contained in IGNITE-29209: create() returns
createSslBundle().context() and always builds a fresh context. The protected
sslCtx cache and no-argument createKeyManagers() hook are removed; affected
subclasses must migrate to loadKeyMaterial() and be recompiled. Sources
providing ready-made contexts can use plain Factory<SSLContext> with unknown
metadata. The API change also keeps a context in communication so new
connections do not reload the store; IGNITE-29210 moves ownership into the
shared node registry.
h3. Review and merge order
All five subtasks are created and their branches are prepared. IGNITE-29208 is
merged. Review and merge IGNITE-29209 next; certificate metadata is carried by
SslBundle and does not depend on SSLContextWrapper.
Open the PR for IGNITE-29210 after IGNITE-29209 merges. Open IGNITE-29211 and
IGNITE-29212 after IGNITE-29210 merges. Automatic renewal and HTTP REST may
then merge in either order.
Include the [prepared integration
commit|https://github.com/anton-vinogradov/ignite/commit/048985910a08fc148373975132e10ad34cfce291]
in whichever of IGNITE-29211 and IGNITE-29212 merges second. It adds HTTP REST
renewal documentation, Javadoc and a test showing that a new HTTPS connection
receives the automatically renewed certificate. Apply it and run the test
before merging that second PR.
h3. Updating branches after a squash merge
Before opening a dependent PR, create a new review branch from the current
master. Keep the prepared branch and record the exact head of its prerequisite
that was squash-merged. For example, prepare IGNITE-29210 after IGNITE-29209
has been squash-merged. Here upstream is apache/ignite and origin is the
contributor fork:
{code:bash}
git fetch upstream master
git fetch origin refs/heads/ignite-29210:refs/remotes/origin/ignite-29210
git switch -c ignite-29210-review upstream/master
git diff <recorded-ignite-29209-head> origin/ignite-29210 | git apply --index
git diff --cached --check
git diff --cached
{code}
Resolve any rejected hunks, run the relevant tests, then commit and push the
new review branch. This preserves the prepared branches and requires no
force-push. If a PR is already open, merge master into its branch normally
instead. When integrating the API change with master, retain the SSL wrapper
regression and new SSL test registrations in SecurityTestSuite.
When combining automatic renewal and HTTP REST, retain
CurrentSslContext.engineGetDefaultSSLParameters(). It must forward to the
active context so Jetty retains the configured protocols and cipher suites.
Check both TLS settings and HTTPS renewal after resolving conflicts.
h3. Completion criteria
Each PR includes its tests and documentation and passes CI on its current head.
Update dependent branches after their prerequisites merge so reviewers see only
the changes belonging to that task.
Reload checks available certificate metadata and supported TLS settings.
Administrators remain responsible for peer trust and testing new connections.
Close this umbrella after all five parts merge and the combined solution passes
SSL tests, including mutual TLS and compatibility with existing configurations.
[PR #13335|https://github.com/apache/ignite/pull/13335] remains the reference
implementation until the split is merged.
was:
Allow administrators to replace TLS certificates and trust stores without
restarting nodes. When an external system supplies new certificates, allow
Ignite to load them automatically before the current chain expires.
h3. What each part provides and what uses it
# IGNITE-29208 preserves the peer address when SSLContextWrapper creates an
engine. This fixes existing addressed client engines and lets IGNITE-29209 wrap
contexts for metadata without losing their peer address. [PR
#13750|https://github.com/apache/ignite/pull/13750] is open.
# IGNITE-29209 provides fresh context creation and metadata from the same
key-store load. IGNITE-29210 uses the chain to check dates and report status,
and privateKeyMissing to reject a replacement with no private key. IGNITE-29211
uses the chain's expiry to schedule renewal. [PR
#13751|https://github.com/apache/ignite/pull/13751] is open.
# IGNITE-29210 provides manual reload and status for discovery, communication,
the client connector and binary REST. One context per factory keeps transports
sharing that factory on the same certificate. IGNITE-29211 reuses this
replacement mechanism for scheduled attempts; IGNITE-29212 connects HTTP REST
to it.
# IGNITE-29211 adds scheduling, retries and the ssl.ConsecutiveRenewalFailures
metric. It calls the factory for a fresh context and uses the reload mechanism
to install it. The certificate source remains responsible for supplying
replacements.
# IGNITE-29212 adds httpSslFactory so Jetty HTTP REST can use managed contexts.
This makes HTTPS certificates available to reload and status, and to automatic
renewal once IGNITE-29211 is present.
h3. Review and merge order
All five subtasks are created and their branches are prepared. Merge
IGNITE-29208 first, then IGNITE-29209: metadata wrapping needs the
addressed-engine fix. The API branch includes that fix so it can be tested on
its own.
Open the PR for IGNITE-29210 after IGNITE-29209 merges. Open IGNITE-29211 and
IGNITE-29212 after IGNITE-29210 merges. Automatic renewal and HTTP REST may
then merge in either order.
Include the [prepared integration
commit|https://github.com/anton-vinogradov/ignite/commit/40876edca74c523ec43efd2ef634b27a9fe6f34d]
in whichever of IGNITE-29211 and IGNITE-29212 merges second. It adds HTTP REST
renewal documentation, Javadoc and a test showing that a new HTTPS connection
receives the automatically renewed certificate. Apply it and run the test
before merging that second PR.
h3. Updating branches after a squash merge
Before opening a dependent PR, create a new review branch from the current
master. Keep the prepared branch and record the exact head of its prerequisite
that was squash-merged. For example, prepare IGNITE-29210 after IGNITE-29209
has been squash-merged. Here upstream is apache/ignite and origin is the
contributor fork:
{code:bash}
git fetch upstream master
git fetch origin refs/heads/ignite-29210:refs/remotes/origin/ignite-29210
git switch -c ignite-29210-review upstream/master
git diff <recorded-ignite-29209-head> origin/ignite-29210 | git apply --index
git diff --cached --check
git diff --cached
{code}
Resolve any rejected hunks, run the relevant tests, then commit and push the
new review branch. This preserves the prepared branches and requires no
force-push. If a PR is already open, merge master into its branch normally
instead. When updating IGNITE-29209 after IGNITE-29208, keep both test
registrations in SecurityTestSuite.
When combining automatic renewal and HTTP REST, retain
CurrentSslContext.engineGetDefaultSSLParameters(). It must forward to the
active context so Jetty retains the configured protocols and cipher suites.
Check both TLS settings and HTTPS renewal after resolving conflicts.
h3. Completion criteria
Each PR includes its tests and documentation and passes CI on its current head.
Update dependent branches after their prerequisites merge so reviewers see only
the changes belonging to that task.
Reload checks available certificate metadata and supported TLS settings.
Administrators remain responsible for peer trust and testing new connections.
Close this umbrella after all five parts merge and the combined solution passes
SSL tests, including mutual TLS and compatibility with existing configurations.
[PR #13335|https://github.com/apache/ignite/pull/13335] remains the reference
implementation until the split is merged.
> [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: 6h 50m
> Remaining Estimate: 0h
>
> Allow administrators to replace TLS certificates and trust stores without
> restarting nodes. When an external system supplies new certificates, allow
> Ignite to load them automatically before the current chain expires.
> h3. What each part provides and what uses it
> # IGNITE-29208 preserves the peer address when SSLContextWrapper creates an
> engine. This independently fixes existing addressed client engines. [PR
> #13750|https://github.com/apache/ignite/pull/13750] is merged.
> # IGNITE-29209 builds a fresh SslBundle from one loaded KeyMaterial,
> containing the context and certificate chains for every private-key alias.
> IGNITE-29210 uses the chains to check dates and report status, and an empty
> map to reject a replacement with no private key. IGNITE-29211 uses the
> earliest expiry across all chains to schedule renewal. SSLContextWrapper
> handles TLS parameters only. [PR
> #13751|https://github.com/apache/ignite/pull/13751] is open.
> # IGNITE-29210 owns the current bundle for each factory and provides manual
> reload and status for discovery, communication, the client connector and
> binary REST. It validates and replaces the context and metadata together,
> keeping transports sharing a factory on the same certificates. IGNITE-29211
> reuses this replacement mechanism for scheduled attempts; IGNITE-29212
> connects HTTP REST to it.
> # IGNITE-29211 adds scheduling, retries and the
> ssl.ConsecutiveRenewalFailures metric. It requests a fresh bundle and uses
> the reload mechanism to install it only when every chain is valid and the
> minimum expiry across all chains advances. The certificate source remains
> responsible for supplying replacements.
> # IGNITE-29212 adds httpSslFactory so Jetty HTTP REST can use managed
> contexts. This makes HTTPS certificates available to reload and status, and
> to automatic renewal once IGNITE-29211 is present.
> The factory API change is contained in IGNITE-29209: create() returns
> createSslBundle().context() and always builds a fresh context. The protected
> sslCtx cache and no-argument createKeyManagers() hook are removed; affected
> subclasses must migrate to loadKeyMaterial() and be recompiled. Sources
> providing ready-made contexts can use plain Factory<SSLContext> with unknown
> metadata. The API change also keeps a context in communication so new
> connections do not reload the store; IGNITE-29210 moves ownership into the
> shared node registry.
> h3. Review and merge order
> All five subtasks are created and their branches are prepared. IGNITE-29208
> is merged. Review and merge IGNITE-29209 next; certificate metadata is
> carried by SslBundle and does not depend on SSLContextWrapper.
> Open the PR for IGNITE-29210 after IGNITE-29209 merges. Open IGNITE-29211 and
> IGNITE-29212 after IGNITE-29210 merges. Automatic renewal and HTTP REST may
> then merge in either order.
> Include the [prepared integration
> commit|https://github.com/anton-vinogradov/ignite/commit/048985910a08fc148373975132e10ad34cfce291]
> in whichever of IGNITE-29211 and IGNITE-29212 merges second. It adds HTTP
> REST renewal documentation, Javadoc and a test showing that a new HTTPS
> connection receives the automatically renewed certificate. Apply it and run
> the test before merging that second PR.
> h3. Updating branches after a squash merge
> Before opening a dependent PR, create a new review branch from the current
> master. Keep the prepared branch and record the exact head of its
> prerequisite that was squash-merged. For example, prepare IGNITE-29210 after
> IGNITE-29209 has been squash-merged. Here upstream is apache/ignite and
> origin is the contributor fork:
> {code:bash}
> git fetch upstream master
> git fetch origin refs/heads/ignite-29210:refs/remotes/origin/ignite-29210
> git switch -c ignite-29210-review upstream/master
> git diff <recorded-ignite-29209-head> origin/ignite-29210 | git apply --index
> git diff --cached --check
> git diff --cached
> {code}
> Resolve any rejected hunks, run the relevant tests, then commit and push the
> new review branch. This preserves the prepared branches and requires no
> force-push. If a PR is already open, merge master into its branch normally
> instead. When integrating the API change with master, retain the SSL wrapper
> regression and new SSL test registrations in SecurityTestSuite.
> When combining automatic renewal and HTTP REST, retain
> CurrentSslContext.engineGetDefaultSSLParameters(). It must forward to the
> active context so Jetty retains the configured protocols and cipher suites.
> Check both TLS settings and HTTPS renewal after resolving conflicts.
> h3. Completion criteria
> Each PR includes its tests and documentation and passes CI on its current
> head. Update dependent branches after their prerequisites merge so reviewers
> see only the changes belonging to that task.
> Reload checks available certificate metadata and supported TLS settings.
> Administrators remain responsible for peer trust and testing new connections.
> Close this umbrella after all five parts merge and the combined solution
> passes SSL tests, including mutual TLS and compatibility with existing
> configurations.
> [PR #13335|https://github.com/apache/ignite/pull/13335] remains the reference
> implementation until the split is merged.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
