[
https://issues.apache.org/jira/browse/IGNITE-29210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29210:
--------------------------------------
Description:
Administrators need to replace node certificates and trust stores without
restarting nodes or closing existing connections. Add {{control.sh --ssl
reload}} to apply replacements and {{control.sh --ssl status}} to check what
each server and client node in the current topology has loaded.
h3. How reload works
Discovery, communication, the client connector and binary REST use one managed
context per factory instance. Sharing a factory therefore updates those
transports together; distinct instances remain independent even if they compare
equal. New connections use the replacement context and existing connections
stay open.
The node holds the current {{SslBundle}} from IGNITE-29209 and replaces its
context and metadata together. For {{AbstractSslContextFactory}} and its
subclasses, call {{createSslBundle()}} at startup and on reload; the base
factory builds it from {{loadKeyMaterial()}}. Custom factories follow the
migration contract in IGNITE-29209. A plain {{Factory<SSLContext>}} remains
supported through {{create()}}, with unknown metadata.
Validate the replacement bundle before installing it. Reject unsupported TLS
settings, an invalid date in any supplied certificate chain, a known empty
chain map, or a factory returning the context already in use. Keep the previous
bundle on failure. {{KeyMaterial}} omits entries without a nonempty X.509
chain, so those entries are not validated or reported. A mixed store is not
rejected merely because other entries were skipped. If no chains remain,
instruct the administrator to configure a key entry with a nonempty X.509 chain
before retrying.
Unknown metadata alone must not prevent manual reload, but it means certificate
dates cannot be checked. Reload does not probe connections or establish whether
peers trust the replacement; the administrator must verify that separately.
Report each factory's result and transports on each node. Status reports the
included aliases and chains and the factory's reload outcome, including an
empty chain map, unavailable metadata and invalid certificates. If any selected
node fails, including one that leaves before its job is assigned, return an
error while processing the remaining nodes. Require ADMIN_OPS for both commands
and log each factory reload attempt with its initiator.
h3. Acceptance and documentation
Cover all four transports, mutual TLS and trust changes, new and existing
connections, shared and separate factories, custom factories, partial failures,
departing nodes, permissions, audit and command parsing. Verify that reload
rejects a known empty chain map but accepts valid included chains alongside
omitted entries, and that status reports only included chains. Extend
{{TestCertificateAuthority}} from IGNITE-29209 so tests can set validity dates
and build trust stores with several certificate authorities.
Explain how to prepare peer trust, replace files, verify new connections and
recover from a failed rollout. Distinguish changes to file contents, which
reload applies, from factory settings that require a restart. Application
client stores must be updated separately. Document fresh creation, optional
metadata and serialized calls in the custom-factory reference. Serialization
applies to one node: a factory shared by several nodes in one JVM, or also
called by application code, must support concurrent calls.
h3. Dependencies and remaining work
Implementation, tests and documentation are prepared on {{ignite-29210}}. Open
its PR after IGNITE-29209 is merged and run CI on the updated branch. This task
completes manual reload and status. IGNITE-29211 uses the same replacement
mechanism for scheduled renewal; IGNITE-29212 extends it to HTTP REST. Both
remain separate tasks.
h3. Compatibility
Nodes call {{createSslBundle()}} directly for {{AbstractSslContextFactory}}
implementations. The factory migration in IGNITE-29209 makes {{create()}}
final: move store loading to {{loadKeyMaterial()}}, key-manager customization
to {{createKeyManagers(KeyMaterial)}}, and context decoration to
{{createSslBundle()}} while retaining the certificate chains.
The protected TcpDiscoverySpi.sslSockFactory and
TcpDiscoverySpi.sslSrvSockFactory fields are removed. This is a source and
binary compatibility change for custom TcpDiscoverySpi subclasses that access
these fields; adapt those subclasses before upgrading.
Protocol and cipher-suite names configured through AbstractSslContextFactory
must be supported by the running JVM. Unsupported names now fail node startup
for every managed TCP transport: discovery, communication, the client connector
and binary REST. Some transports previously detected these errors only when
opening a connection.
For a plain Factory<SSLContext>, the node calls create() when registering the
factory at startup and once per requested reload. Transports configured with
the same factory object share its context. As established in IGNITE-29209,
communication does not call create() for each outgoing connection, so custom
factories must not rely on those calls to refresh certificates. To support
reload, each subsequent call must return a fresh SSLContext.
was:
Administrators need to replace node certificates and trust stores without
restarting nodes or closing existing connections. Add {{control.sh --ssl
reload}} to apply replacements and {{control.sh --ssl status}} to check what
each server and client node in the current topology has loaded.
h3. How reload works
Discovery, communication, the client connector and binary REST use one managed
context per factory instance. Sharing a factory therefore updates those
transports together; distinct instances remain independent even if they compare
equal. New connections use the replacement context and existing connections
stay open.
The node holds the current {{SslBundle}} from IGNITE-29209 and replaces its
context and metadata together. For {{AbstractSslContextFactory}} and its
subclasses, call {{createSslBundle()}} at startup and on reload; the base
factory builds it from {{loadKeyMaterial()}}. Custom factories follow the
migration contract in IGNITE-29209. A plain {{Factory<SSLContext>}} remains
supported through {{create()}}, with unknown metadata.
Validate the replacement bundle before installing it. Reject unsupported TLS
settings, an invalid date in any supplied certificate chain, a known empty
private-key map, a private-key alias with a missing or non-X.509 chain, or a
factory returning the context already in use. Keep the previous bundle on
failure. For an unusable chain, identify the alias and instruct the
administrator to add its X.509 chain or remove that private-key entry before
retrying.
Unknown metadata alone must not prevent manual reload, but it means certificate
dates cannot be checked. Reload does not probe connections or establish whether
peers trust the replacement; the administrator must verify that separately.
Report each factory's result and transports on each node. Status reports every
private-key alias and the factory's reload outcome, including missing/non-X.509
chains, unavailable metadata and invalid certificates. If any selected node
fails, including one that leaves before its job is assigned, return an error
while processing the remaining nodes. Require ADMIN_OPS for both commands and
log each factory reload attempt with its initiator.
h3. Acceptance and documentation
Cover all four transports, mutual TLS and trust changes, new and existing
connections, shared and separate factories, custom factories, partial failures,
departing nodes, permissions, audit and command parsing. Extend
{{TestCertificateAuthority}} from IGNITE-29209 so tests can set validity dates
and build trust stores with several certificate authorities.
Explain how to prepare peer trust, replace files, verify new connections and
recover from a failed rollout. Distinguish changes to file contents, which
reload applies, from factory settings that require a restart. Application
client stores must be updated separately. Document fresh creation, optional
metadata and serialized calls in the custom-factory reference. Serialization
applies to one node: a factory shared by several nodes in one JVM, or also
called by application code, must support concurrent calls.
h3. Dependencies and remaining work
Implementation, tests and documentation are prepared on {{ignite-29210}}. Open
its PR after IGNITE-29209 is merged and run CI on the updated branch. This task
completes manual reload and status. IGNITE-29211 uses the same replacement
mechanism for scheduled renewal; IGNITE-29212 extends it to HTTP REST. Both
remain separate tasks.
h3. Compatibility
Nodes call {{createSslBundle()}} directly for {{AbstractSslContextFactory}}
implementations. The factory migration in IGNITE-29209 makes {{create()}}
final: move store loading to {{loadKeyMaterial()}}, key-manager customization
to {{createKeyManagers(KeyMaterial)}}, and context decoration to
{{createSslBundle()}} while retaining the certificate chains.
The protected TcpDiscoverySpi.sslSockFactory and
TcpDiscoverySpi.sslSrvSockFactory fields are removed. This is a source and
binary compatibility change for custom TcpDiscoverySpi subclasses that access
these fields; adapt those subclasses before upgrading.
Protocol and cipher-suite names configured through AbstractSslContextFactory
must be supported by the running JVM. Unsupported names now fail node startup
for every managed TCP transport: discovery, communication, the client connector
and binary REST. Some transports previously detected these errors only when
opening a connection.
For a plain Factory<SSLContext>, the node calls create() when registering the
factory at startup and once per requested reload. Transports configured with
the same factory object share its context. As established in IGNITE-29209,
communication does not call create() for each outgoing connection, so custom
factories must not rely on those calls to refresh certificates. To support
reload, each subsequent call must return a fresh SSLContext.
> Reload TLS certificates on running nodes
> ----------------------------------------
>
> Key: IGNITE-29210
> URL: https://issues.apache.org/jira/browse/IGNITE-29210
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ise
>
> Administrators need to replace node certificates and trust stores without
> restarting nodes or closing existing connections. Add {{control.sh --ssl
> reload}} to apply replacements and {{control.sh --ssl status}} to check what
> each server and client node in the current topology has loaded.
> h3. How reload works
> Discovery, communication, the client connector and binary REST use one
> managed context per factory instance. Sharing a factory therefore updates
> those transports together; distinct instances remain independent even if they
> compare equal. New connections use the replacement context and existing
> connections stay open.
> The node holds the current {{SslBundle}} from IGNITE-29209 and replaces its
> context and metadata together. For {{AbstractSslContextFactory}} and its
> subclasses, call {{createSslBundle()}} at startup and on reload; the base
> factory builds it from {{loadKeyMaterial()}}. Custom factories follow the
> migration contract in IGNITE-29209. A plain {{Factory<SSLContext>}} remains
> supported through {{create()}}, with unknown metadata.
> Validate the replacement bundle before installing it. Reject unsupported TLS
> settings, an invalid date in any supplied certificate chain, a known empty
> chain map, or a factory returning the context already in use. Keep the
> previous bundle on failure. {{KeyMaterial}} omits entries without a nonempty
> X.509 chain, so those entries are not validated or reported. A mixed store is
> not rejected merely because other entries were skipped. If no chains remain,
> instruct the administrator to configure a key entry with a nonempty X.509
> chain before retrying.
> Unknown metadata alone must not prevent manual reload, but it means
> certificate dates cannot be checked. Reload does not probe connections or
> establish whether peers trust the replacement; the administrator must verify
> that separately.
> Report each factory's result and transports on each node. Status reports the
> included aliases and chains and the factory's reload outcome, including an
> empty chain map, unavailable metadata and invalid certificates. If any
> selected node fails, including one that leaves before its job is assigned,
> return an error while processing the remaining nodes. Require ADMIN_OPS for
> both commands and log each factory reload attempt with its initiator.
> h3. Acceptance and documentation
> Cover all four transports, mutual TLS and trust changes, new and existing
> connections, shared and separate factories, custom factories, partial
> failures, departing nodes, permissions, audit and command parsing. Verify
> that reload rejects a known empty chain map but accepts valid included chains
> alongside omitted entries, and that status reports only included chains.
> Extend {{TestCertificateAuthority}} from IGNITE-29209 so tests can set
> validity dates and build trust stores with several certificate authorities.
> Explain how to prepare peer trust, replace files, verify new connections and
> recover from a failed rollout. Distinguish changes to file contents, which
> reload applies, from factory settings that require a restart. Application
> client stores must be updated separately. Document fresh creation, optional
> metadata and serialized calls in the custom-factory reference. Serialization
> applies to one node: a factory shared by several nodes in one JVM, or also
> called by application code, must support concurrent calls.
> h3. Dependencies and remaining work
> Implementation, tests and documentation are prepared on {{ignite-29210}}.
> Open its PR after IGNITE-29209 is merged and run CI on the updated branch.
> This task completes manual reload and status. IGNITE-29211 uses the same
> replacement mechanism for scheduled renewal; IGNITE-29212 extends it to HTTP
> REST. Both remain separate tasks.
> h3. Compatibility
> Nodes call {{createSslBundle()}} directly for {{AbstractSslContextFactory}}
> implementations. The factory migration in IGNITE-29209 makes {{create()}}
> final: move store loading to {{loadKeyMaterial()}}, key-manager customization
> to {{createKeyManagers(KeyMaterial)}}, and context decoration to
> {{createSslBundle()}} while retaining the certificate chains.
> The protected TcpDiscoverySpi.sslSockFactory and
> TcpDiscoverySpi.sslSrvSockFactory fields are removed. This is a source and
> binary compatibility change for custom TcpDiscoverySpi subclasses that access
> these fields; adapt those subclasses before upgrading.
> Protocol and cipher-suite names configured through AbstractSslContextFactory
> must be supported by the running JVM. Unsupported names now fail node startup
> for every managed TCP transport: discovery, communication, the client
> connector and binary REST. Some transports previously detected these errors
> only when opening a connection.
> For a plain Factory<SSLContext>, the node calls create() when registering the
> factory at startup and once per requested reload. Transports configured with
> the same factory object share its context. As established in IGNITE-29209,
> communication does not call create() for each outgoing connection, so custom
> factories must not rely on those calls to refresh certificates. To support
> reload, each subsequent call must return a fresh SSLContext.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
