[
https://issues.apache.org/jira/browse/IGNITE-29209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133033#comment-18133033
]
Anton Vinogradov commented on IGNITE-29209:
-------------------------------------------
[Ignite PR Checker|https://ignite-pr-checker.is-a.dev/?pr=13751] verdict for PR
13751 · RunAll build [9447228|https://ci2.ignite.apache.org/build/9447228] ·
tested
[a360d09|https://github.com/apache/ignite/pull/13751/commits/a360d09a188ebdddf4bc68d771bcfa2f16086d77]
· 149 suites ran, 0 reused
(!) *This run doesn't cover the PR fully:*
- mixed run — Cache (Full API) and Consistency re-ran on fecbd9e, PDS 1 on
b672056, the rest of the RunAll ran on a360d09; only a RunAll of the PR's head
can prove it clean
Everything below is what it did manage to say.
(?) *No blockers found — but the run above can't prove the PR is clean.* 25
failing tests are not blamed on this PR. Re-run after you handle what is listed
above.
_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]._
_The PR is now at {{fecbd9e}}._
♻️ Settled after 2 auto re-run waves: #1 — 2 suites that failed mid-run; #2 — 1
broken suite.
> 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 10m
> 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
> {{createSslBundle()}} returns an {{SslBundle}} containing an initialized
> context and an immutable map of all private-key aliases to their X.509
> chains. {{KeyMaterial}} holds the loaded key store, its key password and
> manager algorithm, so key managers and metadata come from the same store
> load. Multiple private keys are supported; the metadata describes all loaded
> keys, not the certificate selected for a particular connection.
> A {{null}} map means the private-key aliases are unknown. An empty map means
> there are no private keys, while an empty list preserves a private-key alias
> whose X.509 chain is unknown. This lets node reload reject a known keyless
> replacement without rejecting unknown metadata. The API itself continues to
> allow keyless client contexts. {{SSLContextWrapper}} remains responsible only
> for TLS parameters.
> h3. Compatibility and verification
> Preserve source and binary compatibility for existing factories. The
> deprecated {{create()}} retains its original key-manager hook and protected
> {{sslCtx}} cache; it neither inspects nor calls {{createSslBundle()}}. Bundle
> creation is independent of that cache. A new factory implementing only bundle
> creation must also provide an explicit adapter or the legacy key-manager hook
> if it serves {{Factory.create()}} callers.
> Regression coverage checks fresh versus cached contexts, matching metadata
> from one store load, all private-key aliases, defensive copies, and existing
> subclasses and hooks. It also covers a legacy custom store loader returning
> {{null}}: {{create()}} still produces an initialized context and caches it.
> Generate the test stores with explicit keys and certificates. Keep the shared
> generator and its Bouncy Castle dependency in test code for reuse by the
> follow-up tasks.
> Validation: 14 metadata tests and the peer-address regression test pass, as
> do source/binary compatibility checks and Checkstyle. Full CI is still
> pending.
> h3. Dependencies and consumers
> IGNITE-29208's peer-address fix is already in master. The [prepared node
> integration|https://github.com/anton-vinogradov/ignite/compare/ignite-29209...ignite-29210]
> demonstrates the consumers and explicit bundle opt-in for custom factories.
> 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)
