[ 
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 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 missing/non-X.509 chain metadata separately from unknown metadata. Local 
validation: 17 API and communication tests passed on e0dd39eb; the combined 
reload, renewal, HTTP and CLI branches passed 96 tests with two existing JMX 
skips on 5db37359. Checkstyle and Javadoc/doclint passed. The new missing-chain 
regressions fail without the validation guard and pass with it. Full CI remains 
on hold until requested.

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 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.



> 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 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 missing/non-X.509 chain metadata separately from unknown metadata. 
> Local validation: 17 API and communication tests passed on e0dd39eb; the 
> combined reload, renewal, HTTP and CLI branches passed 96 tests with two 
> existing JMX skips on 5db37359. Checkstyle and Javadoc/doclint passed. The 
> new missing-chain regressions fail without the validation guard and pass with 
> it. Full CI remains on hold until requested.
> 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)

Reply via email to