[
https://issues.apache.org/jira/browse/IGNITE-29212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29212:
--------------------------------------
Description:
Let HTTP REST use the same certificate reload and status workflow as the other
node transports. With {{ConnectorConfiguration.httpSslFactory}}, administrators
can rotate HTTPS certificates and trust stores without restarting the
connector. The same registered factory can participate in automatic renewal
once IGNITE-29211 is also present.
h3. Result and acceptance
* Support the built-in Jetty connector and HTTP connectors supplied through
XML. New HTTPS connections use replacement material; established connections
remain usable, and failed reloads retain the working context.
* Preserve factory protocols/cipher suites, applicable Jetty cipher exclusions
and explicitly configured {{SecureRequestCustomizer}} settings. Verify the TLS
settings actually used by Jetty.
* {{httpSslClientAuth=true}} requires a trusted client certificate before and
after certificate/trust changes, and requires {{httpSslFactory}}. Reject a
managed factory combined with the connector's own TLS configuration or the
PROXY protocol.
* Keep existing Jetty-owned TLS working when {{httpSslFactory}} is absent. Test
real HTTPS requests, open/new connections, mutual TLS after trust changes, XML
connectors and rejected startup configurations.
h3. Migration boundaries
Moving TLS ownership from Jetty XML requires a rolling restart. Remove the
connector's own TLS, move stores and enabled protocols/ciphers into the Ignite
factory, and preserve mandatory client authentication, host/SNI checks and
revocation policy. These settings are not all transferred automatically.
The standard Ignite factory has no key-alias selector: preserve an explicitly
selected alias with a store containing only that key, using matching key/store
passwords. {{httpSslClientAuth}} does not represent optional
{{wantClientAuth}}; preserve it with a custom factory or retain Jetty TLS.
Likewise, reproduce Jetty CRL/OCSP checks through suitable trust managers or
retain Jetty TLS. Custom trust managers remain unchanged by reload.
Follow [Migrate TLS from Jetty
XML|https://github.com/anton-vinogradov/ignite/blob/ignite-29212/docs/_docs/restapi.adoc#https-and-certificate-reload]
for the exact steps, including implicit {{SecureRequestCustomizer}} host
checks, and the [ConnectorConfiguration
contracts|https://github.com/anton-vinogradov/ignite/blob/ignite-29212/modules/core/src/main/java/org/apache/ignite/configuration/ConnectorConfiguration.java#L528].
Verify application host names and client certificates after migration. Peer
trust remains an operator responsibility.
h3. Delivery and automatic renewal
Open the PR after IGNITE-29210 merges. This task works independently of
IGNITE-29211.
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 {{271ff0ed}}: all 9 HTTP tests passed, with Checkstyle. The
combined HTTPS renewal test also passed at {{fe6d4afd}}. These are targeted
local checks, not full CI.
was:
Let HTTP REST use the same certificate reload and status workflow as the other
node transports. With {{ConnectorConfiguration.httpSslFactory}}, administrators
can rotate HTTPS certificates and trust stores without restarting the
connector. The same registered factory can participate in automatic renewal
once IGNITE-29211 is also present.
h3. Result and acceptance
* Support the built-in Jetty connector and HTTP connectors supplied through
XML. New HTTPS connections use replacement material; established connections
remain usable, and failed reloads retain the working context.
* Preserve factory protocols/cipher suites, applicable Jetty cipher exclusions
and explicitly configured {{SecureRequestCustomizer}} settings. Verify the TLS
settings actually used by Jetty.
* {{httpSslClientAuth=true}} requires a trusted client certificate before and
after certificate/trust changes, and requires {{httpSslFactory}}. Reject a
managed factory combined with the connector's own TLS configuration or the
PROXY protocol.
* Keep existing Jetty-owned TLS working when {{httpSslFactory}} is absent. Test
real HTTPS requests, open/new connections, mutual TLS after trust changes, XML
connectors and rejected startup configurations.
h3. Migration boundaries
Moving TLS ownership from Jetty XML requires a rolling restart. Remove the
connector's own TLS, move stores and enabled protocols/ciphers into the Ignite
factory, and preserve mandatory client authentication, host/SNI checks and
revocation policy. These settings are not all transferred automatically.
The standard Ignite factory has no key-alias selector: preserve an explicitly
selected alias with a store containing only that key, using matching key/store
passwords. {{httpSslClientAuth}} does not represent optional
{{wantClientAuth}}; preserve it with a custom factory or retain Jetty TLS.
Likewise, reproduce Jetty CRL/OCSP checks through suitable trust managers or
retain Jetty TLS. Custom trust managers remain unchanged by reload.
Follow [Migrate TLS from Jetty
XML|https://github.com/anton-vinogradov/ignite/blob/ignite-29212/docs/_docs/restapi.adoc#https-and-certificate-reload]
for the exact steps, including implicit {{SecureRequestCustomizer}} host
checks, and the [ConnectorConfiguration
contracts|https://github.com/anton-vinogradov/ignite/blob/ignite-29212/modules/core/src/main/java/org/apache/ignite/configuration/ConnectorConfiguration.java#L528].
Verify application host names and client certificates after migration. Peer
trust remains an operator responsibility.
h3. Delivery and automatic renewal
Open the PR after IGNITE-29210 merges. This task works independently of
IGNITE-29211.
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: {{90489d2a}}. All nine standalone HTTPS tests and Checkstyle
passed. The only subsequent change was loading-hook Javadoc; Java code is
unchanged. These are local targeted checks, not full CI.
> Support certificate reload for HTTP REST
> ----------------------------------------
>
> Key: IGNITE-29212
> URL: https://issues.apache.org/jira/browse/IGNITE-29212
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ise
>
> Let HTTP REST use the same certificate reload and status workflow as the
> other node transports. With {{ConnectorConfiguration.httpSslFactory}},
> administrators can rotate HTTPS certificates and trust stores without
> restarting the connector. The same registered factory can participate in
> automatic renewal once IGNITE-29211 is also present.
> h3. Result and acceptance
> * Support the built-in Jetty connector and HTTP connectors supplied through
> XML. New HTTPS connections use replacement material; established connections
> remain usable, and failed reloads retain the working context.
> * Preserve factory protocols/cipher suites, applicable Jetty cipher
> exclusions and explicitly configured {{SecureRequestCustomizer}} settings.
> Verify the TLS settings actually used by Jetty.
> * {{httpSslClientAuth=true}} requires a trusted client certificate before and
> after certificate/trust changes, and requires {{httpSslFactory}}. Reject a
> managed factory combined with the connector's own TLS configuration or the
> PROXY protocol.
> * Keep existing Jetty-owned TLS working when {{httpSslFactory}} is absent.
> Test real HTTPS requests, open/new connections, mutual TLS after trust
> changes, XML connectors and rejected startup configurations.
> h3. Migration boundaries
> Moving TLS ownership from Jetty XML requires a rolling restart. Remove the
> connector's own TLS, move stores and enabled protocols/ciphers into the
> Ignite factory, and preserve mandatory client authentication, host/SNI checks
> and revocation policy. These settings are not all transferred automatically.
> The standard Ignite factory has no key-alias selector: preserve an explicitly
> selected alias with a store containing only that key, using matching
> key/store passwords. {{httpSslClientAuth}} does not represent optional
> {{wantClientAuth}}; preserve it with a custom factory or retain Jetty TLS.
> Likewise, reproduce Jetty CRL/OCSP checks through suitable trust managers or
> retain Jetty TLS. Custom trust managers remain unchanged by reload.
> Follow [Migrate TLS from Jetty
> XML|https://github.com/anton-vinogradov/ignite/blob/ignite-29212/docs/_docs/restapi.adoc#https-and-certificate-reload]
> for the exact steps, including implicit {{SecureRequestCustomizer}} host
> checks, and the [ConnectorConfiguration
> contracts|https://github.com/anton-vinogradov/ignite/blob/ignite-29212/modules/core/src/main/java/org/apache/ignite/configuration/ConnectorConfiguration.java#L528].
> Verify application host names and client certificates after migration. Peer
> trust remains an operator responsibility.
> h3. Delivery and automatic renewal
> Open the PR after IGNITE-29210 merges. This task works independently of
> IGNITE-29211.
> 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 {{271ff0ed}}: all 9 HTTP 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)
