[
https://issues.apache.org/jira/browse/IGNITE-29209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29209:
--------------------------------------
Description:
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.
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.
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: 1h
> Remaining Estimate: 0h
>
> 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.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
