[
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.
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:
Certificate reload needs a fresh SSLContext and metadata that describes the
exact key material loaded into it. Reading the key store again for metadata
could report a different certificate if the source changes between reads.
Add AbstractSslContextFactory.createNew() while preserving the existing cached
create() behavior. Introduce KeyMaterial and a compatible createKeyMaterial()
hook that obtains key managers and their certificate chain from one load.
Existing subclasses using createKeyManagers() and createTrustManagers() must
continue to work. SslContextFactory should obtain its metadata from the store
already used to initialize its key managers.
Extend SSLContextWrapper to carry the chain and distinguish material known to
contain no private key from material whose chain is unknown. Preserve the
existing two-argument constructor and defensively copy metadata. That
constructor retains the chain and missing-key marker when its delegate is
another SSLContextWrapper. Constructors with explicit metadata use the supplied
values instead. A wrapper carrying metadata alone must preserve delegate
behavior without requiring custom SSLParameters.
Tests should cover cached versus fresh creation, one-load consistency, legacy
hooks, defensive copies, wrapper behavior, and stores with zero, one, or
multiple private keys. Document the extension contracts in Javadoc, including
subclasses that override create(). Keep renewal settings and node reload
behavior in their respective follow-up tasks.
Merge IGNITE-29208 first. This branch includes the same peer-address fix
because metadata wrappers must preserve client behavior even with default TLS
settings. After IGNITE-29208 lands, merge master into this branch normally. If
SecurityTestSuite conflicts, retain both test registrations.
The [manual reload
implementation|https://github.com/anton-vinogradov/ignite/compare/ignite-29209...ignite-29210]
shows how the new API is used.
> 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: 0.5h
> 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.
> 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)
