[
https://issues.apache.org/jira/browse/IGNITE-29211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29211:
--------------------------------------
Description:
Load replacement TLS certificates before the current ones expire. An external
source supplies the replacements. Ignite schedules the loads and applies
accepted replacements to new connections.
h3. What to deliver
# Add {{SslContextFactory.setRenewalEnabled(boolean)}} and
{{isRenewalEnabled()}}. Renewal is disabled by default. Changing the setting
requires a node restart. Each node schedules attempts for renewal-enabled
factories used by its started TCP transports. Fail startup if an enabled
factory's key store has no private-key entry with an X.509 chain.
# Start when the first key chain to expire has 15% of its lifetime left, or
immediately if that time has passed. The lifetime runs from the leaf
certificate's start to the earliest expiry in its chain, including CA
certificates. For chains with the same earliest expiry, use the longest
lifetime.
# Add public {{SslContextFactory.getRenewalTime()}} and {{renew()}}. The first
returns the current window's opening time, or {{0}} when renewal is disabled.
The second skips a disabled or closed window. An automatic replacement must
have a key chain, every certificate in its key chains must be within its
validity dates, and the earliest expiry must advance. On failure, keep the
current context and retry, even after expiry. The base retry delay starts at
one minute and doubles up to one hour, with a random addition of up to half of
each delay.
# Serialize manual and automatic loads of one factory. With renewal enabled, a
manual replacement must provide a key chain and may keep the same expiry, for
example for a trust-only change. A successful manual reload recalculates the
schedule on that node and runs the next attempt immediately if it is already
due. Nodes sharing a factory each keep their own schedule and may both query
the source in one window.
# Once shutdown starts, the node starts no more attempts and counts no more
failures. An attempt already loading may still install a replacement that
passes the checks.
# Log the next attempt and failures with the affected transports. Publish
{{ssl.ConsecutiveRenewalFailures}} as the node sum of consecutive automatic
failures per factory, or zero on nodes without renewal. An unchanged expiry
counts as a failure. An accepted automatic replacement or any successful manual
reload clears that factory's count on the node. Skipped attempts, manual
failures and shutdown cancellation do not increment it.
# Document configuration, custom sources and recovery. Sources must bound their
load time because a stuck load can delay node stop and the reload command.
h3. Acceptance
Verify the API and default-off behavior, startup rejection without a chain,
scheduling and dates from a custom key-store loader, invalid and unchanged
replacements, retries after expiry, manual reload, shared factories, shutdown
and counters. Verify rotation on a new TLS connection while an established
connection remains usable.
Depends on [IGNITE-29210|https://issues.apache.org/jira/browse/IGNITE-29210].
[IGNITE-29212|https://issues.apache.org/jira/browse/IGNITE-29212] covers HTTPS
and its renewal verification. No separate status command or certificate
inventory is required.
[Implementation plan for PR #13786|https://github.com/apache/ignite/pull/13786]
was:
Load replacement certificates from the configured source before the current
certificates expire, without an administrator running a command. The source
remains responsible for supplying replacements.
h3. What to deliver
# Make renewal opt-in and disabled by default. Schedule from the earliest
expiry in the loaded key certificate chains, including CA certificates in those
chains. Start when the configured renewal window opens, immediately if already
due. Reject enabling renewal without the required certificate timing.
# Accept an automatic replacement only if every certificate in its key chains
is within its validity dates and the earliest expiry advances. Otherwise keep
the current context and retry with bounded backoff and jitter, including after
expiry.
# Serialize manual and automatic loads. Successful manual reload replans
renewal and may keep the same expiry, including trust-only changes. With
renewal enabled, every accepted replacement must supply timing data.
# Prevent stale attempts and work still loading at shutdown from installing a
context or scheduling further work.
# Log the next attempt and failures. Publish {{ssl.ConsecutiveRenewalFailures}}
as the node sum of consecutive automatic failures per factory. Unchanged expiry
counts as failure; advancing expiry clears that factory's count. Manual
failures, stale attempts and shutdown cancellation do not increment it.
# Document configuration, custom-source requirements, timeouts and recovery.
Use a separate renewal-enabled factory per running node.
h3. Acceptance
Verify scheduling, custom-source timing, invalid and unchanged replacements,
retries after expiry, manual reload interaction, shutdown, metrics and rotation
on a new TLS connection.
Depends on IGNITE-29210. No certificate inventory or separate status command is
required.
[Implementation plan: PR #13786|https://github.com/apache/ignite/pull/13786]
> Renew TLS certificates automatically before expiry
> --------------------------------------------------
>
> Key: IGNITE-29211
> URL: https://issues.apache.org/jira/browse/IGNITE-29211
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ise
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Load replacement TLS certificates before the current ones expire. An external
> source supplies the replacements. Ignite schedules the loads and applies
> accepted replacements to new connections.
> h3. What to deliver
> # Add {{SslContextFactory.setRenewalEnabled(boolean)}} and
> {{isRenewalEnabled()}}. Renewal is disabled by default. Changing the setting
> requires a node restart. Each node schedules attempts for renewal-enabled
> factories used by its started TCP transports. Fail startup if an enabled
> factory's key store has no private-key entry with an X.509 chain.
> # Start when the first key chain to expire has 15% of its lifetime left, or
> immediately if that time has passed. The lifetime runs from the leaf
> certificate's start to the earliest expiry in its chain, including CA
> certificates. For chains with the same earliest expiry, use the longest
> lifetime.
> # Add public {{SslContextFactory.getRenewalTime()}} and {{renew()}}. The
> first returns the current window's opening time, or {{0}} when renewal is
> disabled. The second skips a disabled or closed window. An automatic
> replacement must have a key chain, every certificate in its key chains must
> be within its validity dates, and the earliest expiry must advance. On
> failure, keep the current context and retry, even after expiry. The base
> retry delay starts at one minute and doubles up to one hour, with a random
> addition of up to half of each delay.
> # Serialize manual and automatic loads of one factory. With renewal enabled,
> a manual replacement must provide a key chain and may keep the same expiry,
> for example for a trust-only change. A successful manual reload recalculates
> the schedule on that node and runs the next attempt immediately if it is
> already due. Nodes sharing a factory each keep their own schedule and may
> both query the source in one window.
> # Once shutdown starts, the node starts no more attempts and counts no more
> failures. An attempt already loading may still install a replacement that
> passes the checks.
> # Log the next attempt and failures with the affected transports. Publish
> {{ssl.ConsecutiveRenewalFailures}} as the node sum of consecutive automatic
> failures per factory, or zero on nodes without renewal. An unchanged expiry
> counts as a failure. An accepted automatic replacement or any successful
> manual reload clears that factory's count on the node. Skipped attempts,
> manual failures and shutdown cancellation do not increment it.
> # Document configuration, custom sources and recovery. Sources must bound
> their load time because a stuck load can delay node stop and the reload
> command.
> h3. Acceptance
> Verify the API and default-off behavior, startup rejection without a chain,
> scheduling and dates from a custom key-store loader, invalid and unchanged
> replacements, retries after expiry, manual reload, shared factories, shutdown
> and counters. Verify rotation on a new TLS connection while an established
> connection remains usable.
> Depends on [IGNITE-29210|https://issues.apache.org/jira/browse/IGNITE-29210].
> [IGNITE-29212|https://issues.apache.org/jira/browse/IGNITE-29212] covers
> HTTPS and its renewal verification. No separate status command or certificate
> inventory is required.
> [Implementation plan for PR
> #13786|https://github.com/apache/ignite/pull/13786]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
