[
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 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.
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 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 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.
Add the [prepared integration
commit|https://github.com/anton-vinogradov/ignite/commit/a32c9b35f8147a62df23726874adb785353abc70]
to whichever of the IGNITE-29211 and IGNITE-29212 PRs merges second. It only
changes documentation and Javadoc, to say that HTTP REST certificates from
httpSslFactory also renew automatically. On that PR's branch, run
JettySslContextReloadTest for HTTP REST reload and SslRenewalNodeTest for
automatic renewal.
> 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 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.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
