[
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 from the same
loaded key material. 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 key-store
aliases to nonempty X.509 chains. A {{null}} map means certificate metadata is
unknown; an empty map means no nonempty X.509 chains were found for key
entries. {{SslBundle}} rejects empty lists, including from custom factories.
{{KeyMaterial}} includes chains from key entries only. It skips entries without
a nonempty chain or with a non-X.509 certificate, and does not extract keys or
determine their type for reporting. Multiple chains are supported. The metadata
describes the loaded material, not the certificate selected for a particular
connection, and does not establish private-key availability.
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 a known empty chain map and validates the
included chains. A mixed store is not rejected merely because other entries
were skipped. {{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
included chains from key entries, immutable metadata, custom store loaders and
key-manager wrappers, TLS parameters, and context reuse across communication
connections. Check that missing and non-X.509 chains are omitted, mixed stores
keep their eligible chains without recovering keys for metadata, empty lists
are rejected by {{SslBundle}}, and 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 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.
> 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 50m
> Remaining Estimate: 0h
>
> Provide a fresh SSL context together with the certificate chains from the
> same loaded key material. 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 key-store
> aliases to nonempty X.509 chains. A {{null}} map means certificate metadata
> is unknown; an empty map means no nonempty X.509 chains were found for key
> entries. {{SslBundle}} rejects empty lists, including from custom factories.
> {{KeyMaterial}} includes chains from key entries only. It skips entries
> without a nonempty chain or with a non-X.509 certificate, and does not
> extract keys or determine their type for reporting. Multiple chains are
> supported. The metadata describes the loaded material, not the certificate
> selected for a particular connection, and does not establish private-key
> availability.
> 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 a known empty chain map and validates
> the included chains. A mixed store is not rejected merely because other
> entries were skipped. {{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
> included chains from key entries, immutable metadata, custom store loaders
> and key-manager wrappers, TLS parameters, and context reuse across
> communication connections. Check that missing and non-X.509 chains are
> omitted, mixed stores keep their eligible chains without recovering keys for
> metadata, empty lists are rejected by {{SslBundle}}, and 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)
