[
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/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: {{f313ae1e}}. Local validation in the combined integration
{{ed06380c}}: 86 targeted SSL tests passed, two existing JMX variants were
skipped, and Checkstyle passed. This is local combined validation, not full CI.
was:
HTTP REST certificates configured directly in Jetty XML require a node restart
to replace. Add {{ConnectorConfiguration.httpSslFactory}} to bring HTTPS into
IGNITE-29210's {{control.sh --ssl reload}} and {{control.sh --ssl status}}
workflow. Administrators can then rotate its certificate and trust store
without restarting the connector.
h3. How HTTPS uses the managed context
Support the built-in Jetty connector and HTTP connectors supplied through XML.
New HTTPS connections use the replacement context; existing connections remain
usable. A failed reload retains the working context. Preserve the factory's
protocols and cipher suites, Jetty's applicable cipher exclusions and existing
SecureRequestCustomizer settings.
HTTP REST registers {{httpSslFactory}} with IGNITE-29210 and uses the
forwarding context owned by that factory. It does not create a separate bundle
or metadata mechanism. Reload calls the same factory {{init()}} as the other
registered transports. Custom factories follow the migration contract in
IGNITE-29209.
Honor {{httpSslClientAuth=true}} by requiring a trusted client certificate
before and after certificate and trust changes; reject this setting without
httpSslFactory. Reject a managed factory combined with the connector's own TLS
or the PROXY protocol, because this integration adds TLS directly to an HTTP
connector. Without httpSslFactory, existing XML TLS and client-authentication
settings continue working unchanged.
h3. Migration and acceptance
Document the changes needed to transfer TLS ownership from Jetty XML:
* Remove the connector's own TLS configuration, either an SslConnectionFactory
item or an SslContextFactory$Server constructor argument, and configure the
stores through httpSslFactory using matching key/store passwords. If the Jetty
configuration selected a specific certificate alias, use a store containing
only that intended private key because the standard Ignite factory has no
key-alias setting. Other stores may contain multiple private keys.
* Move protocols and cipher suites to the Ignite factory, retaining Jetty's
applicable exclusions. Copy needClientAuth=true to httpSslClientAuth=true so
client certificates do not become optional. If the existing setup uses
wantClientAuth, preserve optional client authentication in a custom SSL context
factory and verify it before switching, or keep TLS in Jetty XML;
httpSslClientAuth does not represent that setting.
* Preserve SecureRequestCustomizer settings, including a customizer Jetty
previously added implicitly with sniHostCheck=true. Add it explicitly to
HttpConfiguration when needed to retain that check. Explain host/SNI checks and
verify HTTPS with application host names and client certificates.
* Preserve certificate revocation checks. Jetty settings such as
validatePeerCerts, crlPath and enableOCSP are not transferred. Configure the
equivalent policy through the Ignite factory's trustManagers, or retain TLS in
Jetty XML.
* Restart nodes one at a time to apply the new configuration. Reload keeps any
trustManagers set on the factory, so it does not change which certificates they
accept.
Test reload for open and new connections and for client certificates after a
trust store change. Also test Jetty XML connectors, TLS set only in Jetty XML
and settings that stop the node from starting. Check at startup which cipher
suites Jetty enables and excludes.
h3. Dependencies and remaining work
Implementation, tests and documentation are prepared on {{ignite-29212}}. Open
its PR after IGNITE-29210 merges and run CI on the updated branch. HTTP REST
uses the shared context mechanism; automatic scheduling remains in the
independent IGNITE-29211 task.
After both IGNITE-29211 and IGNITE-29212 are present, apply the single
[prepared integration
commit|https://github.com/anton-vinogradov/ignite/commit/e1a7c86c428cf775ef86750bfdca746d1cdeb88c]
to the PR that merges second. It replaces the previous integration commits; do
not apply the old patch list as well. It updates HTTP REST renewal
documentation and Javadoc and adds an HTTPS test proving that automatic renewal
presents the replacement certificate on a new connection. On that combined
branch, run JettySslContextReloadTest and SslRenewalNodeTest.
> 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/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: {{f313ae1e}}. Local validation in the combined integration
> {{ed06380c}}: 86 targeted SSL tests passed, two existing JMX variants were
> skipped, and Checkstyle passed. This is local combined validation, not full
> CI.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
