[
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
{{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.
was:
Provide fresh SSL contexts with metadata describing the key material actually
loaded into them. IGNITE-29210 will use this API to validate replacement
certificates before installing a context and to report certificate status.
IGNITE-29211 will use the chain's expiry to schedule automatic renewal; HTTP
REST in IGNITE-29212 will reuse the reload support.
h3. Fresh contexts and matching metadata
Add AbstractSslContextFactory.createNew() without reading or replacing the
context cached by create(). Return key managers and certificate metadata
together through KeyMaterial and createKeyMaterial(). SslContextFactory must
obtain both from the same key-store load: rereading the store could report a
certificate different from the one in the context.
h3. Rejecting replacements without a private key
Reload must distinguish known absence of a private key from an unknown
certificate chain. The current API reports known absence through
privateKeyMissing. If a node keystore is accidentally replaced with a
trust-only store, context creation can succeed, but IGNITE-29210 must reject
the replacement and keep the old context. An unknown chain can instead mean
custom key managers or multiple private keys. Keyless client contexts must
remain valid when mutual TLS is not used.
h3. Compatibility and verification
SslContextFactory uses createKeyMaterial() directly. Preserve source and binary
compatibility for existing subclasses: the default material hook adapts
deprecated createKeyManagers() with an unknown chain, and existing
trust-manager hooks and adapter calls continue to work. Document that a
subclass implementing its own create() must also implement createNew() to
rebuild from the same sources.
Expose metadata through SSLContextWrapper with defensive copies. Preserve its
existing constructor and delegate behavior, including peer addresses and SSL
settings. The existing two-argument constructor inherits metadata from a
wrapped SSLContextWrapper; constructors with explicit metadata use their
arguments.
Verify cached versus fresh creation, one-load consistency, old-subclass
compatibility, defensive copies, delegate behavior, and the missing-key
distinction for stores with zero, one or multiple private keys. Generate the
test stores with explicit keys, authorities and validity dates so each test
shows what it expects. Keep the shared certificate generator and its Bouncy
Castle dependency in test code for reuse by the follow-up tasks.
h3. Dependencies and consumers
Merge IGNITE-29208 first: metadata wrapping needs its addressed-engine fix. The
[prepared reload
implementation|https://github.com/anton-vinogradov/ignite/compare/ignite-29209...ignite-29210]
shows the API consumers. Node reload, status reporting, scheduling and HTTP
REST integration belong to the follow-up tasks.
> 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 10m
> 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
> {{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.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
