[
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.
# The renewal window opens when the first key chain to expire has 15% of its
lifetime left; if that time has passed, renewal starts at once. 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 runs one automatic attempt and does nothing if renewal is disabled
or the window is closed. 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 load or validation failure, {{renew()}} throws
and keeps the current context. The node retries, 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 waiting for another load of the factory must exit without
loading. An attempt admitted while the node was running may finish and 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. A skipped attempt also clears
it. Manual failures and shutdown cancellation do not increment it.
# Document configuration, the {{ssl.ConsecutiveRenewalFailures}} metric,
overrides of {{loadKeyStore()}} or {{openFileInputStream()}}, and recovery. An
override must bound its 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 an overridden {{loadKeyStore()}}, 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: PR #13786|https://github.com/apache/ignite/pull/13786]
was:
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 load or validation
failure, {{renew()}} throws and keeps the current context. The node retries,
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]
> 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.
> # The renewal window opens when the first key chain to expire has 15% of its
> lifetime left; if that time has passed, renewal starts at once. 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 runs one automatic attempt and does nothing if renewal
> is disabled or the window is closed. 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 load or validation failure,
> {{renew()}} throws and keeps the current context. The node retries, 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 waiting for another load of the factory must exit
> without loading. An attempt admitted while the node was running may finish
> and 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. A skipped attempt also
> clears it. Manual failures and shutdown cancellation do not increment it.
> # Document configuration, the {{ssl.ConsecutiveRenewalFailures}} metric,
> overrides of {{loadKeyStore()}} or {{openFileInputStream()}}, and recovery.
> An override must bound its 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 an overridden {{loadKeyStore()}}, 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: PR #13786|https://github.com/apache/ignite/pull/13786]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
