[
https://issues.apache.org/jira/browse/IGNITE-29211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29211:
--------------------------------------
Description:
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.
was:
Load externally supplied replacement certificates before the current chains
expire, without a reload command for each scheduled rotation. Ignite does not
issue certificates or watch files; trust-store-only changes and immediate
operator action still use {{--ssl reload}}.
h3. Result and acceptance
* Renewal is opt-in. Schedule from the earliest expiry across all reported
X.509 chains, including CA certificates. Require available, nonempty metadata
at startup and on replacement. Respect custom factory policies for enabling
renewal and selecting its window.
* Install the whole replacement only when all reported certificates are
currently valid and the earliest expiry advances. Alias changes are allowed.
Failure or unchanged expiry retains current material; retry with bounded
backoff and jitter, including after expiry.
* Serialize automatic attempts with manual reloads. Calling protected
{{init()}} from a factory subclass also replans renewal; stale or interrupted
attempts must not install material. Shutdown ends renewal without counting
cancellation as a reload or renewal failure.
* Show the next attempt in {{--ssl status}}. {{ssl.ConsecutiveRenewalFailures}}
sums unsuccessful automatic attempts across distinct factories, counting a
shared factory once. Unchanged expiry counts; failed manual reloads do not.
Reset a factory's count only when an installed bundle advances earliest expiry.
h3. Operation and lifecycle
Configure renewal before startup; changing its settings requires a restart. Use
a separate renewal-enabled factory per running node; it may attach to a new
node after the old executor stops. Reusing an initialized factory retains
material until {{init()}} or successful renewal.
Entries without eligible X.509 chains are omitted from monitoring. Renewal does
not prove peer trust. See [rollout and
recovery|https://github.com/anton-vinogradov/ignite/blob/ignite-29211/docs/_docs/security/ssl-tls.adoc#renewing-certificates-automatically]
and the [setting contracts and
defaults|https://github.com/anton-vinogradov/ignite/blob/b8980a0a0ee08191c90387965a787f90630d3b0c/modules/commons/src/main/java/org/apache/ignite/ssl/AbstractSslContextFactory.java#L170].
h3. Delivery and HTTP integration
Depends on IGNITE-29210. IGNITE-29212 may merge before or after this task. Once
both are present, include the [joint integration
commit|https://github.com/anton-vinogradov/ignite/commit/889a3fde5349850cc29428f0511bc51f42a6d599]
once in the PR that merges second; it adds HTTPS renewal coverage and
documentation.
At {{b8980a0a}}, all 51 metadata, renewal and node-lifecycle tests passed.
Checkstyle passed.
> 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 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.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
