[
https://issues.apache.org/jira/browse/IGNITE-29209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29209:
--------------------------------------
Description:
Keep an 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
{{AbstractSslContextFactory}} owns the accepted {{SslBundle}}. Its final
{{create()}} method initializes the factory on first use and returns the same
forwarding context thereafter, without reloading the stores. {{sslBundle()}}
returns the accepted snapshot, initializing the factory if necessary.
{{init()}} loads a candidate through {{createSslBundle()}}, checks that its
context can create an engine, and publishes the context and metadata together.
A failed call leaves the previous bundle in use. The public
{{createSslBundle()}} hook still loads a fresh candidate; calling it alone does
not replace the accepted material. Certificate-date checks and rejection of
known empty metadata belong to IGNITE-29210.
After initialization, newly created engines and newly obtained socket factories
use the accepted material. Previously obtained engines, socket factories and
sockets retain their original material. Configure the factory before its first
use; runtime contexts are not serialized with its configuration.
Removing the protected {{sslCtx}} field and no-argument {{createKeyManagers()}}
hook, and making {{create()}} final, requires affected subclasses to be updated
and recompiled. Remove custom context caching: the base factory retains the
accepted bundle, and {{init()}} loads a replacement.
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.
Transports that share an {{AbstractSslContextFactory}} instance obtain the same
forwarding context and accepted material. Communication retains its context
between connections, so opening a connection does not reload stores.
IGNITE-29210 adds node registration, manual reload and status without
introducing a second owner of the bundle.
h3. Verification and consumers
Verify fresh loading through {{init()}}, cached access through {{create()}} and
{{sslBundle()}}, concurrent first initialization, retry after failure,
preservation of the accepted bundle when a replacement fails, and forwarding to
replacement material. Also cover 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}}.
The initialization API is published in [PR
#13751|https://github.com/apache/ignite/pull/13751] at {{22e3ec58}}. All 16 API
tests passed locally, and the two strengthened tests passed again; Checkstyle
and Javadoc/doclint passed. The previous full CI run does not cover this
rework; no new full CI result is claimed.
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 transport registration and delegation to the factory-owned
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 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.
Summary: Add SSL bundle metadata and explicit factory initialization
(was: Add fresh SSL contexts with certificate metadata)
> Add SSL bundle metadata and explicit factory initialization
> -----------------------------------------------------------
>
> 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: 3h 40m
> Remaining Estimate: 0h
>
> Keep an 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
> {{AbstractSslContextFactory}} owns the accepted {{SslBundle}}. Its final
> {{create()}} method initializes the factory on first use and returns the same
> forwarding context thereafter, without reloading the stores. {{sslBundle()}}
> returns the accepted snapshot, initializing the factory if necessary.
> {{init()}} loads a candidate through {{createSslBundle()}}, checks that its
> context can create an engine, and publishes the context and metadata
> together. A failed call leaves the previous bundle in use. The public
> {{createSslBundle()}} hook still loads a fresh candidate; calling it alone
> does not replace the accepted material. Certificate-date checks and rejection
> of known empty metadata belong to IGNITE-29210.
> After initialization, newly created engines and newly obtained socket
> factories use the accepted material. Previously obtained engines, socket
> factories and sockets retain their original material. Configure the factory
> before its first use; runtime contexts are not serialized with its
> configuration.
> Removing the protected {{sslCtx}} field and no-argument
> {{createKeyManagers()}} hook, and making {{create()}} final, requires
> affected subclasses to be updated and recompiled. Remove custom context
> caching: the base factory retains the accepted bundle, and {{init()}} loads a
> replacement.
> 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.
> Transports that share an {{AbstractSslContextFactory}} instance obtain the
> same forwarding context and accepted material. Communication retains its
> context between connections, so opening a connection does not reload stores.
> IGNITE-29210 adds node registration, manual reload and status without
> introducing a second owner of the bundle.
> h3. Verification and consumers
> Verify fresh loading through {{init()}}, cached access through {{create()}}
> and {{sslBundle()}}, concurrent first initialization, retry after failure,
> preservation of the accepted bundle when a replacement fails, and forwarding
> to replacement material. Also cover 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}}.
> The initialization API is published in [PR
> #13751|https://github.com/apache/ignite/pull/13751] at {{22e3ec58}}. All 16
> API tests passed locally, and the two strengthened tests passed again;
> Checkstyle and Javadoc/doclint passed. The previous full CI run does not
> cover this rework; no new full CI result is claimed.
> 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 transport registration and delegation to the factory-owned
> 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)
