[
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 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 unknown. Multiple private keys are supported.
The metadata describes the loaded material, not the certificate selected for a
particular connection. The API permits keyless client contexts; node reload can
reject a known keyless replacement. {{SSLContextWrapper}} remains responsible
only for TLS parameters.
h3. Factory contract and migration
{{create()}} remains the supported {{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 changes source and binary compatibility for subclasses that use them.
Update and recompile those subclasses. Return the loaded store through
{{loadKeyMaterial()}} and use the base factory's bundle construction. Move
store loading from custom {{create()}} overrides into that hook. 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. 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, TLS parameters,
and context reuse across communication connections. Local validation on
e11f5b28: 11 tests passed, including metadata, peer-address and communication
context reuse. The combined reload, renewal, CLI and HTTP branches passed 85
tests with one existing JMX skip on cbaf94e0. Checkstyle and Javadoc/doclint
passed. The communication regression fails with the old transport
implementation and passes with the context holder. A new full CI run is on hold
at the author's request.
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
{{createSslBundle()}} returns an {{SslBundle}} containing an initialized
context and an immutable map of all private-key aliases to their X.509 chains.
{{KeyMaterial}} holds the loaded key store, its key password and manager
algorithm, so key managers and metadata come from the same store load. Multiple
private keys are supported; the metadata describes all loaded keys, not the
certificate selected for a particular connection.
A {{null}} map means the private-key aliases are unknown. An empty map means
there are no private keys, while an empty list preserves a private-key alias
whose X.509 chain is unknown. This lets node reload reject a known keyless
replacement without rejecting unknown metadata. The API itself continues to
allow keyless client contexts. {{SSLContextWrapper}} remains responsible only
for TLS parameters.
h3. Compatibility and verification
Preserve source and binary compatibility for existing factories. The deprecated
{{create()}} retains its original key-manager hook and protected {{sslCtx}}
cache; it neither inspects nor calls {{createSslBundle()}}. Bundle creation is
independent of that cache. A new factory implementing only bundle creation must
also provide an explicit adapter or the legacy key-manager hook if it serves
{{Factory.create()}} callers.
Regression coverage checks fresh versus cached contexts, matching metadata from
one store load, all private-key aliases, defensive copies, and existing
subclasses and hooks. It also covers a legacy custom store loader returning
{{null}}: {{create()}} still produces an initialized context and caches it.
Generate the test stores with explicit keys and certificates. Keep the shared
generator and its Bouncy Castle dependency in test code for reuse by the
follow-up tasks.
Validation: 14 metadata tests and the peer-address regression test pass, as do
source/binary compatibility checks and Checkstyle. Full CI is still pending.
h3. Dependencies and consumers
IGNITE-29208's peer-address fix is already in master. The [prepared node
integration|https://github.com/anton-vinogradov/ignite/compare/ignite-29209...ignite-29210]
demonstrates the consumers and explicit bundle opt-in for custom factories.
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 20m
> 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 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 unknown. Multiple private keys are
> supported. The metadata describes the loaded material, not the certificate
> selected for a particular connection. The API permits keyless client
> contexts; node reload can reject a known keyless replacement.
> {{SSLContextWrapper}} remains responsible only for TLS parameters.
> h3. Factory contract and migration
> {{create()}} remains the supported {{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 changes source and binary compatibility for
> subclasses that use them. Update and recompile those subclasses. Return the
> loaded store through {{loadKeyMaterial()}} and use the base factory's bundle
> construction. Move store loading from custom {{create()}} overrides into that
> hook. 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. 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, TLS
> parameters, and context reuse across communication connections. Local
> validation on e11f5b28: 11 tests passed, including metadata, peer-address and
> communication context reuse. The combined reload, renewal, CLI and HTTP
> branches passed 85 tests with one existing JMX skip on cbaf94e0. Checkstyle
> and Javadoc/doclint passed. The communication regression fails with the old
> transport implementation and passes with the context holder. A new full CI
> run is on hold at the author's request.
> 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)
