[
https://issues.apache.org/jira/browse/IGNITE-29209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29209:
--------------------------------------
Description:
Provide a fresh SSL context together with the certificate chains actually
loaded into it. IGNITE-29210 needs this information to validate replacement
certificates and report status; IGNITE-29211 needs certificate expiry dates to
schedule renewal. Reading the store separately for reporting could describe
different material from the context in use.
h3. Result
{{AbstractSslContextFactory}} builds an {{SslBundle}} from {{KeyMaterial}}
containing the loaded key store, key password and manager algorithm.
{{SslContextFactory}} loads the store. Key managers and certificate metadata
come from that same store load. The loaded store must remain unchanged while
any context built from it is in use, because some key-manager providers read it
during handshakes. Load a new store when replacing certificates.
The bundle contains an initialized context and an immutable map of every
private-key alias to its X.509 chain. A {{null}} map means the aliases are
unknown; an empty map means there are no private keys; an empty list retains a
private-key alias whose chain is missing or contains a non-X.509 certificate.
Multiple private keys are supported. The metadata describes the loaded
material, not the certificate selected for a particular connection.
For a client context without private keys, supply an empty loaded store. The
store passed to {{KeyMaterial}} and the result of {{loadKeyMaterial()}} must
both be non-null. Node reload rejects known keyless replacements and entries
with unusable chains. {{SSLContextWrapper}} remains responsible only for TLS
parameters.
h3. Factory contract and migration
{{create()}} is the final {{Factory<SSLContext>}} entry point and returns
{{createSslBundle().context()}}. Every call builds a fresh context. The
consumer owns the context it keeps in use; the factory has no context cache.
Removing the protected {{sslCtx}} cache and no-argument {{createKeyManagers()}}
hook, and making {{create()}} final, requires affected subclasses to be updated
and recompiled. Move store loading into {{loadKeyMaterial()}} and key-manager
customization into the typed {{createKeyManagers(KeyMaterial)}} hook. Its
default implementation creates managers from the supplied material; an override
can wrap them while preserving the association with the reported chains. Move
customization of an already built context from {{create()}} to
{{createSslBundle()}}, retaining its certificate chains. A source providing a
ready-made context can use a plain {{Factory<SSLContext>}} with unknown
metadata. Callers that depended on repeated {{create()}} calls returning the
same context must retain it themselves.
Keep a context in the communication transport so new connections do not reload
the store after the factory cache is removed. Before IGNITE-29210 introduces
shared node ownership, each enabled TLS transport creates and retains its own
context at startup; a shared factory therefore loads its stores separately for
each transport. This consumer adjustment is part of the API change; shared node
ownership and reload remain in IGNITE-29210.
h3. Verification and consumers
Verify fresh creation through both entry points, one-load consistency, all
private-key aliases, immutable metadata, custom store loaders and key-manager
wrappers, TLS parameters, and context reuse across communication connections.
Check that a private key with a non-X.509 chain keeps its alias with an empty
list, while unknown metadata stays {{null}}. Local test results are in [PR
#13751|https://github.com/apache/ignite/pull/13751].
IGNITE-29208's independent peer-address fix is already merged. The [prepared
node
integration|https://github.com/anton-vinogradov/ignite/compare/ignite-29209...ignite-29210]
demonstrates the API consumers and ownership of the current bundle.
IGNITE-29210 owns manual reload, validation and status; IGNITE-29211 adds
automatic renewal; IGNITE-29212 connects HTTP REST to the shared reload
mechanism. Those changes are outside this API task.
was:
Provide a fresh SSL context together with the certificate chains actually
loaded into it. IGNITE-29210 needs this information to validate replacement
certificates and report status; IGNITE-29211 needs certificate expiry dates to
schedule renewal. Reading the store separately for reporting could describe
different material from the context in use.
h3. Result
{{AbstractSslContextFactory}} builds an {{SslBundle}} from {{KeyMaterial}}
containing the loaded key store, key password and manager algorithm.
{{SslContextFactory}} loads the store. Key managers and certificate metadata
come from that same store load. The loaded store must remain unchanged while
any context built from it is in use, because some key-manager providers read it
during handshakes. Load a new store when replacing certificates.
The bundle contains an initialized context and an immutable map of every
private-key alias to its X.509 chain. A {{null}} map means the aliases are
unknown; an empty map means there are no private keys; an empty list retains a
private-key alias whose chain is missing or contains a non-X.509 certificate.
Multiple private keys are supported. The metadata describes the loaded
material, not the certificate selected for a particular connection.
For a client context without private keys, supply an empty loaded store. The
store passed to {{KeyMaterial}} and the result of {{loadKeyMaterial()}} must
both be non-null. Node reload rejects known keyless replacements and entries
with unusable chains. {{SSLContextWrapper}} remains responsible only for TLS
parameters.
h3. Factory contract and migration
{{create()}} is the final {{Factory<SSLContext>}} entry point and returns
{{createSslBundle().context()}}. Every call builds a fresh context. The
consumer owns the context it keeps in use; the factory has no context cache.
Removing the protected {{sslCtx}} cache and no-argument {{createKeyManagers()}}
hook, and making {{create()}} final, requires affected subclasses to be updated
and recompiled. Move store loading into {{loadKeyMaterial()}} and key-manager
customization into the typed {{createKeyManagers(KeyMaterial)}} hook. Its
default implementation creates managers from the supplied material; an override
can wrap them while preserving the association with the reported chains. Move
customization of an already built context from {{create()}} to
{{createSslBundle()}}, retaining its certificate chains. A source providing a
ready-made context can use a plain {{Factory<SSLContext>}} with unknown
metadata. Callers that depended on repeated {{create()}} calls returning the
same context must retain it themselves.
Keep a context in the communication transport so new connections do not reload
the store after the factory cache is removed. Before IGNITE-29210 introduces
shared node ownership, each enabled TLS transport creates and retains its own
context at startup; a shared factory therefore loads its stores separately for
each transport. This consumer adjustment is part of the API change; shared node
ownership and reload remain in IGNITE-29210.
h3. Verification and consumers
Verify fresh creation through both entry points, one-load consistency, all
private-key aliases, immutable metadata, custom store loaders and key-manager
wrappers, TLS parameters, and context reuse across communication connections.
Check missing/non-X.509 chain metadata separately from unknown metadata. Local
validation: 17 API and communication tests passed on e0dd39eb; the combined
reload, renewal, HTTP and CLI branches passed 96 tests with two existing JMX
skips on 5db37359. Checkstyle and Javadoc/doclint passed. The new missing-chain
regressions fail without the validation guard and pass with it. Full CI remains
on hold until requested.
IGNITE-29208's independent peer-address fix is already merged. The [prepared
node
integration|https://github.com/anton-vinogradov/ignite/compare/ignite-29209...ignite-29210]
demonstrates the API consumers and ownership of the current bundle.
IGNITE-29210 owns manual reload, validation and status; IGNITE-29211 adds
automatic renewal; IGNITE-29212 connects HTTP REST to the shared reload
mechanism. Those changes are outside this API task.
> Add fresh SSL contexts with certificate metadata
> ------------------------------------------------
>
> Key: IGNITE-29209
> URL: https://issues.apache.org/jira/browse/IGNITE-29209
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ise
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Provide a fresh SSL context together with the certificate chains actually
> loaded into it. IGNITE-29210 needs this information to validate replacement
> certificates and report status; IGNITE-29211 needs certificate expiry dates
> to schedule renewal. Reading the store separately for reporting could
> describe different material from the context in use.
> h3. Result
> {{AbstractSslContextFactory}} builds an {{SslBundle}} from {{KeyMaterial}}
> containing the loaded key store, key password and manager algorithm.
> {{SslContextFactory}} loads the store. Key managers and certificate metadata
> come from that same store load. The loaded store must remain unchanged while
> any context built from it is in use, because some key-manager providers read
> it during handshakes. Load a new store when replacing certificates.
> The bundle contains an initialized context and an immutable map of every
> private-key alias to its X.509 chain. A {{null}} map means the aliases are
> unknown; an empty map means there are no private keys; an empty list retains
> a private-key alias whose chain is missing or contains a non-X.509
> certificate. Multiple private keys are supported. The metadata describes the
> loaded material, not the certificate selected for a particular connection.
> For a client context without private keys, supply an empty loaded store. The
> store passed to {{KeyMaterial}} and the result of {{loadKeyMaterial()}} must
> both be non-null. Node reload rejects known keyless replacements and entries
> with unusable chains. {{SSLContextWrapper}} remains responsible only for TLS
> parameters.
> h3. Factory contract and migration
> {{create()}} is the final {{Factory<SSLContext>}} entry point and returns
> {{createSslBundle().context()}}. Every call builds a fresh context. The
> consumer owns the context it keeps in use; the factory has no context cache.
> Removing the protected {{sslCtx}} cache and no-argument
> {{createKeyManagers()}} hook, and making {{create()}} final, requires
> affected subclasses to be updated and recompiled. Move store loading into
> {{loadKeyMaterial()}} and key-manager customization into the typed
> {{createKeyManagers(KeyMaterial)}} hook. Its default implementation creates
> managers from the supplied material; an override can wrap them while
> preserving the association with the reported chains. Move customization of an
> already built context from {{create()}} to {{createSslBundle()}}, retaining
> its certificate chains. A source providing a ready-made context can use a
> plain {{Factory<SSLContext>}} with unknown metadata. Callers that depended on
> repeated {{create()}} calls returning the same context must retain it
> themselves.
> Keep a context in the communication transport so new connections do not
> reload the store after the factory cache is removed. Before IGNITE-29210
> introduces shared node ownership, each enabled TLS transport creates and
> retains its own context at startup; a shared factory therefore loads its
> stores separately for each transport. This consumer adjustment is part of the
> API change; shared node ownership and reload remain in IGNITE-29210.
> h3. Verification and consumers
> Verify fresh creation through both entry points, one-load consistency, all
> private-key aliases, immutable metadata, custom store loaders and key-manager
> wrappers, TLS parameters, and context reuse across communication connections.
> Check that a private key with a non-X.509 chain keeps its alias with an empty
> list, while unknown metadata stays {{null}}. Local test results are in [PR
> #13751|https://github.com/apache/ignite/pull/13751].
> IGNITE-29208's independent peer-address fix is already merged. The [prepared
> node
> integration|https://github.com/anton-vinogradov/ignite/compare/ignite-29209...ignite-29210]
> demonstrates the API consumers and ownership of the current bundle.
> IGNITE-29210 owns manual reload, validation and status; IGNITE-29211 adds
> automatic renewal; IGNITE-29212 connects HTTP REST to the shared reload
> mechanism. Those changes are outside this API task.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
