[
https://issues.apache.org/jira/browse/IGNITE-29211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29211:
--------------------------------------
Description:
Allow a node to load certificates supplied by an external system before the
current chain expires. Manual file replacement remains a separate workflow:
replace the files and run {{--ssl reload}}.
h3. Required behavior
* Add opt-in renewal settings to AbstractSslContextFactory, disabled by
default. Schedule attempts from the certificate lifetime and earliest expiry in
its chain. Refuse startup when renewal is enabled but the factory supplies no
chain metadata.
* Reuse reload validation. Install only a valid replacement whose chain expires
later. If the chain is unchanged, loading fails or the replacement is rejected,
keep the current context and retry with bounded backoff and jitter. Continue
retrying after expiry. Show the next attempt in {{--ssl status}} and log
failures.
* Publish one node metric, {{ssl.ConsecutiveRenewalFailures}}. Sum the
consecutive unsuccessful automatic attempts of distinct factory instances,
counting a shared factory once. An unchanged certificate is an unsuccessful
attempt.
* Reset only the affected factory's count when automatic renewal or manual
reload installs a chain with a later expiry. Failed manual reloads do not
increment the metric.
* Serialize manual and automatic work for each factory. Replan after successful
reload and prevent an obsolete automatic attempt from installing its result.
Run automatic work in the node's operation context.
* Interrupt and finish renewal work during shutdown. Cancellation must not
count as a renewal failure or overwrite the last reload result.
h3. Tests and documentation
Cover scheduling, chain expiry, retries after expiry, unchanged certificates,
counter aggregation and reset, races with manual reload, shutdown and
default-off behavior. Explain when to enable renewal, how to inspect failures
and how the metric changes.
h3. Dependencies and remaining work
The branch {{ignite-29211}} is prepared. Open its PR after IGNITE-29210 is
merged, then run CI on the updated branch. HTTP REST integration in
IGNITE-29212 is independent.
When both IGNITE-29211 and IGNITE-29212 are present, document HTTP REST
automatic renewal in the renewal configuration table, HTTP REST guide and
ConnectorConfiguration Javadoc. Include these updates with whichever change
merges second.
was:
Allow a node to pick up certificates delivered by an external system before the
loaded chain expires. Add opt-in renewal settings to AbstractSslContextFactory,
disabled by default, and schedule attempts from the certificate lifetime and
earliest expiry in its chain. Enabling renewal without chain metadata must fail
at startup.
Use the existing reload validation and install only a valid replacement whose
chain expires later. An unchanged chain, a loading error, or a rejected
replacement leaves the current context in use and triggers retries with bounded
backoff and jitter. Continue retrying after expiry, with useful logs and the
next attempt time in --ssl status.
Publish ssl.ConsecutiveRenewalFailures as the sum of consecutive unsuccessful
automatic attempts across distinct factory instances. Count a shared factory
once, including unchanged-certificate attempts. Reset only the affected
factory's count when automatic renewal or manual reload installs a chain with a
later expiry. Failed manual reloads must not increment this metric.
Serialize manual and automatic work for each factory, replan after successful
reload, and prevent a superseded renewal attempt from installing a stale
context. Interrupt and finish renewal work during shutdown without recording
cancellation as a renewal failure. Automatic work must use the node's operation
context.
Include renewal and metric documentation. Tests should cover timing, chain
expiry, retries after expiry, unchanged certificates, counter aggregation and
reset, manual reload races, shutdown, and default-off behavior.
Depends on IGNITE-29210; it can proceed independently of HTTP REST integration.
> 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
>
> Allow a node to load certificates supplied by an external system before the
> current chain expires. Manual file replacement remains a separate workflow:
> replace the files and run {{--ssl reload}}.
> h3. Required behavior
> * Add opt-in renewal settings to AbstractSslContextFactory, disabled by
> default. Schedule attempts from the certificate lifetime and earliest expiry
> in its chain. Refuse startup when renewal is enabled but the factory supplies
> no chain metadata.
> * Reuse reload validation. Install only a valid replacement whose chain
> expires later. If the chain is unchanged, loading fails or the replacement is
> rejected, keep the current context and retry with bounded backoff and jitter.
> Continue retrying after expiry. Show the next attempt in {{--ssl status}} and
> log failures.
> * Publish one node metric, {{ssl.ConsecutiveRenewalFailures}}. Sum the
> consecutive unsuccessful automatic attempts of distinct factory instances,
> counting a shared factory once. An unchanged certificate is an unsuccessful
> attempt.
> * Reset only the affected factory's count when automatic renewal or manual
> reload installs a chain with a later expiry. Failed manual reloads do not
> increment the metric.
> * Serialize manual and automatic work for each factory. Replan after
> successful reload and prevent an obsolete automatic attempt from installing
> its result. Run automatic work in the node's operation context.
> * Interrupt and finish renewal work during shutdown. Cancellation must not
> count as a renewal failure or overwrite the last reload result.
> h3. Tests and documentation
> Cover scheduling, chain expiry, retries after expiry, unchanged certificates,
> counter aggregation and reset, races with manual reload, shutdown and
> default-off behavior. Explain when to enable renewal, how to inspect failures
> and how the metric changes.
> h3. Dependencies and remaining work
> The branch {{ignite-29211}} is prepared. Open its PR after IGNITE-29210 is
> merged, then run CI on the updated branch. HTTP REST integration in
> IGNITE-29212 is independent.
> When both IGNITE-29211 and IGNITE-29212 are present, document HTTP REST
> automatic renewal in the renewal configuration table, HTTP REST guide and
> ConnectorConfiguration Javadoc. Include these updates with whichever change
> merges second.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
