[
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 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.
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/b7c500ae589ca52f80ffdf3c3862d17f1a5ec67f]
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 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.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
