[ 
https://issues.apache.org/jira/browse/IGNITE-29211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Vinogradov updated IGNITE-29211:
--------------------------------------
    Description: 
Automatically load certificates delivered by an external system before the 
current chain expires. That system issues and publishes replacements; Ignite 
loads them at scheduled attempts. Manual file replacement and trust-store-only 
changes still use {{--ssl reload}}: renewal does not watch files for changes.

h3. How renewal works

Add opt-in settings to AbstractSslContextFactory, disabled by default. Use the 
certificate lifetime and earliest chain expiry to schedule attempts, including 
an expiring CA certificate. Enabling renewal without chain metadata must 
prevent startup because its due time cannot be determined. Metadata remains 
required on later loads.

Reuse IGNITE-29210's validation and context replacement. Install only a valid 
chain that expires later, so a successful renewal extends the time the node can 
use its certificate. If material is unchanged, loading fails or validation 
rejects it, retain the current context and retry with bounded backoff and 
jitter, including after expiry. Show the next attempt in {{--ssl status}} and 
log the cause.

Serialize renewal and manual reload for each factory, replan after a successful 
reload and prevent an obsolete automatic attempt from installing its result. 
Use the node's operation context so scheduled work is attributed to the node. 
Shutdown interrupts and finishes renewal work; cancellation must neither count 
as failure nor overwrite the last reload result.

h3. Monitoring and acceptance

Publish one node metric, {{ssl.ConsecutiveRenewalFailures}}, so monitoring can 
detect unsuccessful delivery or loading. Sum consecutive unsuccessful automatic 
attempts across distinct factories and count a shared factory once. An 
unchanged chain counts as unsuccessful. Reset only the affected factory's count 
when renewal or manual reload installs a later-expiring chain. Failed manual 
reloads do not increment this metric.

Test scheduling, chain expiry, retries after expiry, unchanged material, metric 
aggregation and reset, reload races and shutdown. Verify default-off behavior, 
including manual reload with unknown metadata and no renewal messages. Explain 
delivery prerequisites, enabling renewal, inspecting failures and recovering 
with reload.

h3. Dependencies and remaining work

Implementation, tests and documentation are prepared on {{ignite-29211}}. Open 
its PR after IGNITE-29210 is merged and run CI on the updated branch. HTTP REST 
integration in IGNITE-29212 is independent.

Once both features are present, include the [prepared integration 
commit|https://github.com/anton-vinogradov/ignite/commit/b7c500ae589ca52f80ffdf3c3862d17f1a5ec67f]
 in whichever PR merges second. It supplies HTTP renewal documentation, Javadoc 
and an HTTPS test for automatic replacement with a later-expiring chain. Re-run 
the test on the updated branch.

  was:
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.


> 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
>
> Automatically load certificates delivered by an external system before the 
> current chain expires. That system issues and publishes replacements; Ignite 
> loads them at scheduled attempts. Manual file replacement and 
> trust-store-only changes still use {{--ssl reload}}: renewal does not watch 
> files for changes.
> h3. How renewal works
> Add opt-in settings to AbstractSslContextFactory, disabled by default. Use 
> the certificate lifetime and earliest chain expiry to schedule attempts, 
> including an expiring CA certificate. Enabling renewal without chain metadata 
> must prevent startup because its due time cannot be determined. Metadata 
> remains required on later loads.
> Reuse IGNITE-29210's validation and context replacement. Install only a valid 
> chain that expires later, so a successful renewal extends the time the node 
> can use its certificate. If material is unchanged, loading fails or 
> validation rejects it, retain the current context and retry with bounded 
> backoff and jitter, including after expiry. Show the next attempt in {{--ssl 
> status}} and log the cause.
> Serialize renewal and manual reload for each factory, replan after a 
> successful reload and prevent an obsolete automatic attempt from installing 
> its result. Use the node's operation context so scheduled work is attributed 
> to the node. Shutdown interrupts and finishes renewal work; cancellation must 
> neither count as failure nor overwrite the last reload result.
> h3. Monitoring and acceptance
> Publish one node metric, {{ssl.ConsecutiveRenewalFailures}}, so monitoring 
> can detect unsuccessful delivery or loading. Sum consecutive unsuccessful 
> automatic attempts across distinct factories and count a shared factory once. 
> An unchanged chain counts as unsuccessful. Reset only the affected factory's 
> count when renewal or manual reload installs a later-expiring chain. Failed 
> manual reloads do not increment this metric.
> Test scheduling, chain expiry, retries after expiry, unchanged material, 
> metric aggregation and reset, reload races and shutdown. Verify default-off 
> behavior, including manual reload with unknown metadata and no renewal 
> messages. Explain delivery prerequisites, enabling renewal, inspecting 
> failures and recovering with reload.
> h3. Dependencies and remaining work
> Implementation, tests and documentation are prepared on {{ignite-29211}}. 
> Open its PR after IGNITE-29210 is merged and run CI on the updated branch. 
> HTTP REST integration in IGNITE-29212 is independent.
> Once both features are present, include the [prepared integration 
> commit|https://github.com/anton-vinogradov/ignite/commit/b7c500ae589ca52f80ffdf3c3862d17f1a5ec67f]
>  in whichever PR merges second. It supplies HTTP renewal documentation, 
> Javadoc and an HTTPS test for automatic replacement with a later-expiring 
> chain. Re-run the test on the updated branch.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to