[
https://issues.apache.org/jira/browse/IGNITE-29211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29211:
--------------------------------------
Description:
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 expiries tie,
the earliest window wins. A subclass may override {{isRenewalEnabled()}} and
{{getRenewBeforeFraction()}}. The node reads their values at startup and checks
the fraction when renewal is enabled.
* 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
executor during a load keeps the previous material and counters.
* {{--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. 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/74669cb8120c16c6f00ae622e7d41a33ccd17265]
once in the PR merged second.
was:
Let the node load replacement certificates supplied to its configured source
before the earliest certificate in its current chains expires. Set
{{renewalEnabled}} before startup. Setting changes take effect after a node
restart. Operators can still use manual reload for trust-store changes or
immediate rotation.
h3. Result
* Schedule the first attempt from the earliest expiry across all reported
chains, including CA certificates. The first attempt starts in the final
{{renewBeforeFraction}} of the chain lifetime (15% by default). If expiries
tie, the earliest window wins. Only retry times are randomized. The node needs
at least one X.509 chain and validates the configured renewal fraction at
startup.
* Accept a fresh context only if all replacement chains are currently valid and
their earliest expiry advances. Otherwise keep the current material and retry
with bounded backoff and jitter. Manual and scheduled loads run one at a time.
A successful manual reload replans renewal. Superseded attempts do nothing. If
the node stops its executor while loading material, it keeps the accepted
material and the counters.
* {{--ssl status}} reports the next planned attempt.
{{ssl.ConsecutiveRenewalFailures}} is the node-wide sum of consecutive
unsuccessful automatic attempts across distinct factories. It is zero on a node
without TLS. An unchanged expiry counts. Advancing the earliest expiry resets
that factory's count.
Use a separate renewal-enabled factory per running node. One thread handles
renewal on a node, so remote sources need timeouts and must respond to
interruption. The [renewal
guide|https://github.com/anton-vinogradov/ignite/blob/ignite-29211/docs/_docs/security/ssl-tls.adoc#renewing-certificates-automatically]
covers delivery timing, key passwords, retries and recovery.
[PR #13786 and validation|https://github.com/apache/ignite/pull/13786] builds
on IGNITE-29210. Once this task and IGNITE-29212 are present, apply the [HTTPS
renewal test and
documentation|https://github.com/anton-vinogradov/ignite/commit/b4f505eeea2a448b67e2234b5bb3368768646e25]
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: 40m
> Remaining Estimate: 0h
>
> 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 expiries
> tie, the earliest window wins. A subclass may override {{isRenewalEnabled()}}
> and {{getRenewBeforeFraction()}}. The node reads their values at startup and
> checks the fraction when renewal is enabled.
> * 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
> executor during a load keeps the previous material and counters.
> * {{--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. 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/74669cb8120c16c6f00ae622e7d41a33ccd17265]
> once in the PR merged second.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
