[
https://issues.apache.org/jira/browse/IGNITE-29211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29211:
--------------------------------------
Description:
Load replacement certificates supplied by an external system before the current
chains expire. This removes the need to issue a reload command for each
scheduled certificate 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
certificate metadata at startup and on replacement.
* Install the whole replacement only when all reported certificates are
currently valid and the earliest expiry advances. Alias changes are allowed.
Retain current material on failure or unchanged expiry and retry with bounded
backoff and jitter, including after expiry.
* Serialize automatic attempts and manual {{init()}}. Direct initialization
replans renewal; stale or interrupted attempts must not install material. Node
shutdown ends renewal without recording cancellation as a failed reload or
renewal.
* Show the next attempt in {{--ssl status}}. The node metric
{{ssl.ConsecutiveRenewalFailures}} sums unsuccessful automatic attempts across
distinct factories, counting a shared factory once. Unchanged expiry counts;
failed manual reloads do not. Reset the affected count only when an installed
bundle advances earliest expiry.
* Test expiry across chains, unchanged/invalid material, retries, metrics,
direct initialization, races, shutdown and restart. Default configuration
schedules no renewal work.
* Respect custom factory policies that disable renewal or select its renewal
window.
h3. Operation and lifecycle
Supply and trust replacements before the renewal window. Configure renewal
before startup and restart nodes to change its settings. Use a separate
renewal-enabled factory per running node; it may attach to a new node after the
old executor stops. Reusing the same initialized factory retains material until
explicit initialization or successful renewal.
See [Prepare Certificate Delivery and Enable
Renewal|https://github.com/anton-vinogradov/ignite/blob/ignite-29211/docs/_docs/security/ssl-tls.adoc#renewing-certificates-automatically]
for rollout and recovery, and the [setting contracts and
defaults|https://github.com/anton-vinogradov/ignite/blob/ignite-29211/modules/commons/src/main/java/org/apache/ignite/ssl/AbstractSslContextFactory.java#L163]
for scheduling details. Entries without eligible X.509 chains are omitted from
monitoring. No renewal result proves that peers trust the replacement.
h3. Delivery and HTTP integration
Open the PR after IGNITE-29210 merges. IGNITE-29212 is an independent consumer
of the same reload mechanism and may merge before or after this task.
After IGNITE-29211 and IGNITE-29212 are both present, include the single [joint
integration
commit|https://github.com/anton-vinogradov/ignite/commit/889a3fde5349850cc29428f0511bc51f42a6d599]
in the PR that merges second. Apply it once, without replaying older
integration patches. It adds HTTPS automatic-renewal coverage and the
corresponding documentation/Javadoc. Run {{JettySslContextReloadTest}} and
{{SslRenewalNodeTest}} on that combined branch.
Local validation at {{a4bd1b1c}}: all 35 renewal and node tests passed, with
Checkstyle. The combined HTTPS renewal test also passed at {{fe6d4afd}}. These
are targeted local checks, not full CI.
was:
Load replacement certificates supplied by an external system before the current
chains expire. This removes the need to issue a reload command for each
scheduled certificate 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
certificate metadata at startup and on replacement.
* Install the whole replacement only when all reported certificates are
currently valid and the earliest expiry advances. Alias changes are allowed.
Retain current material on failure or unchanged expiry and retry with bounded
backoff and jitter, including after expiry.
* Serialize automatic attempts and manual {{init()}}. Direct initialization
replans renewal; stale or interrupted attempts must not install material. Node
shutdown ends renewal without recording cancellation as a failed reload or
renewal.
* Show the next attempt in {{--ssl status}}. The node metric
{{ssl.ConsecutiveRenewalFailures}} sums unsuccessful automatic attempts across
distinct factories, counting a shared factory once. Unchanged expiry counts;
failed manual reloads do not. Reset the affected count only when an installed
bundle advances earliest expiry.
* Test expiry across chains, unchanged/invalid material, retries, metrics,
direct initialization, races, shutdown and restart. Default configuration
schedules no renewal work.
* Respect custom factory policies that disable renewal or select its renewal
window.
h3. Operation and lifecycle
Supply and trust replacements before the renewal window. Configure renewal
before startup and restart nodes to change its settings. Use a separate
renewal-enabled factory per running node; it may attach to a new node after the
old executor stops. Reusing the same initialized factory retains material until
explicit initialization or successful renewal.
See [Prepare Certificate Delivery and Enable
Renewal|https://github.com/anton-vinogradov/ignite/blob/ignite-29211/docs/_docs/security/ssl-tls.adoc#renewing-certificates-automatically]
for rollout and recovery, and the [setting contracts and
defaults|https://github.com/anton-vinogradov/ignite/blob/ignite-29211/modules/commons/src/main/java/org/apache/ignite/ssl/AbstractSslContextFactory.java#L155]
for scheduling details. Entries without eligible X.509 chains are omitted from
monitoring. No renewal result proves that peers trust the replacement.
h3. Delivery and HTTP integration
Open the PR after IGNITE-29210 merges. IGNITE-29212 is an independent consumer
of the same reload mechanism and may merge before or after this task.
After IGNITE-29211 and IGNITE-29212 are both present, include the single [joint
integration
commit|https://github.com/anton-vinogradov/ignite/commit/e1a7c86c428cf775ef86750bfdca746d1cdeb88c]
in the PR that merges second. Apply it once, without replaying older
integration patches. It adds HTTPS automatic-renewal coverage and the
corresponding documentation/Javadoc. Run {{JettySslContextReloadTest}} and
{{SslRenewalNodeTest}} on that combined branch.
Final head: {{5c5aebec}}. The standalone branch passed a clean compile, all 35
renewal/node tests and Checkstyle, including overridden factory settings and
shutdown/restart behavior. These are local targeted checks, not full CI.
> 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
>
> Load replacement certificates supplied by an external system before the
> current chains expire. This removes the need to issue a reload command for
> each scheduled certificate 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
> certificate metadata at startup and on replacement.
> * Install the whole replacement only when all reported certificates are
> currently valid and the earliest expiry advances. Alias changes are allowed.
> Retain current material on failure or unchanged expiry and retry with bounded
> backoff and jitter, including after expiry.
> * Serialize automatic attempts and manual {{init()}}. Direct initialization
> replans renewal; stale or interrupted attempts must not install material.
> Node shutdown ends renewal without recording cancellation as a failed reload
> or renewal.
> * Show the next attempt in {{--ssl status}}. The node metric
> {{ssl.ConsecutiveRenewalFailures}} sums unsuccessful automatic attempts
> across distinct factories, counting a shared factory once. Unchanged expiry
> counts; failed manual reloads do not. Reset the affected count only when an
> installed bundle advances earliest expiry.
> * Test expiry across chains, unchanged/invalid material, retries, metrics,
> direct initialization, races, shutdown and restart. Default configuration
> schedules no renewal work.
> * Respect custom factory policies that disable renewal or select its renewal
> window.
> h3. Operation and lifecycle
> Supply and trust replacements before the renewal window. Configure renewal
> before startup and restart nodes to change its settings. Use a separate
> renewal-enabled factory per running node; it may attach to a new node after
> the old executor stops. Reusing the same initialized factory retains material
> until explicit initialization or successful renewal.
> See [Prepare Certificate Delivery and Enable
> Renewal|https://github.com/anton-vinogradov/ignite/blob/ignite-29211/docs/_docs/security/ssl-tls.adoc#renewing-certificates-automatically]
> for rollout and recovery, and the [setting contracts and
> defaults|https://github.com/anton-vinogradov/ignite/blob/ignite-29211/modules/commons/src/main/java/org/apache/ignite/ssl/AbstractSslContextFactory.java#L163]
> for scheduling details. Entries without eligible X.509 chains are omitted
> from monitoring. No renewal result proves that peers trust the replacement.
> h3. Delivery and HTTP integration
> Open the PR after IGNITE-29210 merges. IGNITE-29212 is an independent
> consumer of the same reload mechanism and may merge before or after this task.
> After IGNITE-29211 and IGNITE-29212 are both present, include the single
> [joint integration
> commit|https://github.com/anton-vinogradov/ignite/commit/889a3fde5349850cc29428f0511bc51f42a6d599]
> in the PR that merges second. Apply it once, without replaying older
> integration patches. It adds HTTPS automatic-renewal coverage and the
> corresponding documentation/Javadoc. Run {{JettySslContextReloadTest}} and
> {{SslRenewalNodeTest}} on that combined branch.
> Local validation at {{a4bd1b1c}}: all 35 renewal and node tests passed, with
> Checkstyle. The combined HTTPS renewal test also passed at {{fe6d4afd}}.
> These are targeted local checks, not full CI.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
