[
https://issues.apache.org/jira/browse/IGNITE-29211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29211:
--------------------------------------
Description:
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.
was:
Let a node load replacement certificates delivered by an external issuer before
the earliest certificate in its current chains expires. Enable renewal on the
factory before startup. 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. Prefer the earliest window when expiries
tie. 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. A manual reload replans renewal and supersedes
attempts for the old context. Stopping the node ends pending work without
counting cancellation as a failure.
* {{--ssl status}} reports the next planned attempt.
{{ssl.ConsecutiveRenewalFailures}} sums unsuccessful automatic attempts per
distinct factory. 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/d554ba23f34e7227f6c998284934a3e1af426d2b]
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
>
> 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.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
