[ 
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 {{--ssl reload}} and {{--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/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:
HTTP REST certificates configured in Jetty XML currently require a node restart 
to replace. Add {{ConnectorConfiguration.httpSslFactory}} and 
{{httpSslClientAuth}} so HTTPS can use the node's managed SSL context and 
participate in reload and status.

h3. Required behavior

* Support the built-in Jetty connector and HTTP connectors supplied through 
Jetty XML. Preserve the factory's protocols and cipher suites, Jetty's 
applicable cipher exclusions and existing SecureRequestCustomizer settings.
* Refuse startup if httpSslFactory is combined with a connector's own TLS or 
the PROXY protocol. Also refuse httpSslClientAuth=true without httpSslFactory.
* Keep existing Jetty XML TLS configurations working unchanged when 
httpSslFactory is not configured.
* Use the new context for new HTTPS connections and keep existing connections 
usable. A failed reload must retain the working context.
* Keep client authentication enforced after certificate and trust-store changes.

h3. Tests and documentation

Cover certificate reload, existing connections, failed replacement, mutual TLS, 
trust-store changes, supported XML connectors, configuration errors and legacy 
XML compatibility. Check both the factory's allowed cipher suites and the 
suites excluded by Jetty, before and after reload.

Explain migration from Jetty XML: key-store requirements, protocols and cipher 
suites, client authentication, customizers that must be preserved, the required 
restart and verification with the application's host names and certificates.

h3. Dependencies and remaining work

The branch {{ignite-29212}} is prepared. Open its PR after IGNITE-29210 is 
merged, then run CI on the updated branch. Keep this integration independent of 
automatic renewal in IGNITE-29211.

When both IGNITE-29211 and IGNITE-29212 are present, cherry-pick the [prepared 
integration 
commit|https://github.com/anton-vinogradov/ignite/commit/b7c500ae589ca52f80ffdf3c3862d17f1a5ec67f]
 into whichever change merges second. It contains the renewal configuration 
table, HTTP REST guide and ConnectorConfiguration Javadoc, plus 
JettySslContextRenewalTest. The test enables renewal on httpSslFactory and 
checks that a new HTTPS connection receives a certificate chain with a later 
expiry date. The test and Checkstyle pass on the combined branches. Re-run them 
after applying the commit to master.


> 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 {{--ssl reload}} and {{--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/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