[
https://issues.apache.org/jira/browse/IGNITE-29209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134207#comment-18134207
]
Anton Vinogradov commented on IGNITE-29209:
-------------------------------------------
[Ignite PR Checker|https://ignite-pr-checker.is-a.dev/?pr=13751] verdict for PR
13751 · RunAll build [9453950|https://ci2.ignite.apache.org/build/9453950] ·
tested
[6459a46|https://github.com/apache/ignite/pull/13751/commits/6459a46c8db0d9afbec35dc1a144933fb7c40f39]
· 149 suites ran, 0 reused
(/) *No blockers* — nothing in this run looks caused by this PR. 20 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 — 4 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: 3.5h
> Remaining Estimate: 0h
>
> Provide a fresh SSL context together with the certificate chains from the
> same loaded key material. 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 key-store
> aliases to nonempty X.509 chains. A {{null}} map means certificate metadata
> is unknown; an empty map means no nonempty X.509 chains were found for key
> entries. {{SslBundle}} rejects empty lists, including from custom factories.
> {{KeyMaterial}} includes chains from key entries only. It skips entries
> without a nonempty chain or with a non-X.509 certificate, and does not
> extract keys or determine their type for reporting. Multiple chains are
> supported. The metadata describes the loaded material, not the certificate
> selected for a particular connection, and does not establish private-key
> availability.
> 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 a known empty chain map and validates
> the included chains. A mixed store is not rejected merely because other
> entries were skipped. {{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()}}. For custom key managers,
> override {{createSslBundle()}} to initialize a fresh context with those
> managers, configure its trust and TLS settings, and return matching
> certificate metadata. For customization of an already built context, call
> {{super.createSslBundle()}} and retain its certificate chains in the returned
> bundle.
> 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
> included chains from key entries, immutable metadata, custom store loaders,
> TLS parameters, and context reuse across communication connections. Check
> that missing and non-X.509 chains are omitted, mixed stores keep their
> eligible chains without recovering keys for metadata, empty lists are
> rejected by {{SslBundle}}, and 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)
