[
https://issues.apache.org/jira/browse/IGNITE-29212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29212:
--------------------------------------
Description:
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 uses the current context owned by IGNITE-29210; it does not create a
separate bundle or metadata mechanism. 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 SslConnectionFactory 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 Ignite 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.
* Preserve SecureRequestCustomizer settings. Explain host/SNI checks and verify
HTTPS with application host names and client certificates.
* Restart nodes one at a time to apply this configuration change. Subsequent
certificate and trust-store replacements can use reload.
Test successful and failed reload, existing connections, mutual TLS and trust
changes, supported XML connectors, invalid combinations and unchanged legacy
XML behavior. Check allowed and excluded cipher suites before and after reload.
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.
Once both features are present, include the [prepared integration
commit|https://github.com/anton-vinogradov/ignite/commit/048985910a08fc148373975132e10ad34cfce291]
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:
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.
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 SslConnectionFactory and configure the stores through httpSslFactory.
Use a store containing only the intended private key, since Ignite has no
key-alias setting, and matching key/store passwords.
* 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.
* Preserve SecureRequestCustomizer settings. Explain host/SNI checks and verify
HTTPS with application host names and client certificates.
* Restart nodes one at a time to apply this configuration change. Subsequent
certificate and trust-store replacements can use reload.
Test successful and failed reload, existing connections, mutual TLS and trust
changes, supported XML connectors, invalid combinations and unchanged legacy
XML behavior. Check allowed and excluded cipher suites before and after reload.
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.
Once both features are present, include the [prepared integration
commit|https://github.com/anton-vinogradov/ignite/commit/40876edca74c523ec43efd2ef634b27a9fe6f34d]
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.
> 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
>
> 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 uses the current context owned by IGNITE-29210; it does not create
> a separate bundle or metadata mechanism. 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 SslConnectionFactory 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 Ignite 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.
> * Preserve SecureRequestCustomizer settings. Explain host/SNI checks and
> verify HTTPS with application host names and client certificates.
> * Restart nodes one at a time to apply this configuration change. Subsequent
> certificate and trust-store replacements can use reload.
> Test successful and failed reload, existing connections, mutual TLS and trust
> changes, supported XML connectors, invalid combinations and unchanged legacy
> XML behavior. Check allowed and excluded cipher suites before and after
> reload.
> 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.
> Once both features are present, include the [prepared integration
> commit|https://github.com/anton-vinogradov/ignite/commit/048985910a08fc148373975132e10ad34cfce291]
> 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)
