[
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 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]
was:
A node can load replacement certificates delivered to its configured source
before its earliest chain expires. Enable {{renewalEnabled}} before startup.
Use manual reload for trust-store changes or immediate rotation.
h3. Result
* Schedule renewal from the earliest expiry across all reported X.509 chains,
including CA certificates. The first attempt falls in the last
{{renewBeforeFraction}} of the chain lifetime, 15% by default. If several
chains expire at the same time, renewal starts when the first of their windows
opens. The node reads renewal settings at startup. With renewal enabled, it
fails to start if the factory reports no X.509 chain or cannot report its
chains.
* Install a fresh context only when all replacement chains are valid and their
earliest expiry advances. Otherwise keep the current material and retry with
bounded backoff, including after expiry. Only retries are randomized.
* Manual and scheduled loads run one at a time. A successful manual reload
replans renewal. An attempt for the old context does nothing. Stopping the node
while a renewal attempt reads its source keeps the previous material and
counters. With renewal enabled, manual reload also requires the factory to
report its chains.
* {{--ssl status}} shows the next attempt. The node metric
{{ssl.ConsecutiveRenewalFailures}} sums consecutive unsuccessful attempts
across its factories, including attempts with unchanged expiry. Advancing the
earliest expiry clears that factory's count. On a node without TLS the metric
is zero.
Use a separate renewal-enabled factory per running node: a node with renewal
enabled fails to start if another running node already uses the same instance.
Remote sources need a timeout and must respond to interruption. [Renewal and
recovery
guide|https://github.com/anton-vinogradov/ignite/blob/ignite-29211/docs/_docs/security/ssl-tls.adoc#renewing-certificates-automatically].
Builds on IGNITE-29210. Code and validation are in [PR
#13786|https://github.com/apache/ignite/pull/13786]. Once both this task and
IGNITE-29212 are present, include the [joint HTTPS renewal test and
documentation|https://github.com/anton-vinogradov/ignite/commit/34c84b8dee8043b33878b2510c8f8321afd25694]
once in the PR merged second.
> 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 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]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
