[
https://issues.apache.org/jira/browse/IGNITE-29209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133312#comment-18133312
]
Anton Vinogradov commented on IGNITE-29209:
-------------------------------------------
[Ignite PR Checker|https://ignite-pr-checker.is-a.dev/?pr=13751] verdict for PR
13751 · RunAll build [9448194|https://ci2.ignite.apache.org/build/9448194] ·
tested
[8a99c99|https://github.com/apache/ignite/pull/13751/commits/8a99c9926e2095c452461b35b48564ae862a474e]
· 149 suites ran, 0 reused
(/) *No blockers* — nothing in this run looks caused by this PR. 22 failing
tests are not blamed on this PR.
_What each label means and what to do: [verdict
glossary|https://github.com/anton-vinogradov/ignite-pr-checker/blob/main/docs/features.md#verdict-glossary]._
♻️ Settled after 1 auto re-run wave: #1 — 2 suites that failed mid-run.
> 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 40m
> 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 that a private key with a non-X.509 chain keeps its alias with an empty
> list, while unknown metadata stays {{null}}. Local test results are in [PR
> #13751|https://github.com/apache/ignite/pull/13751].
> 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)
