Pluggable SSLContextProvider for in-memory key and trust stores by nkrivenko · Pull Request #1344 · quickfix-j/quickfixj

nkrivenko · 2026-10-14T07:19:23Z

Summary

Adds a pluggable SSLContextProvider so applications can supply the SSLContext for SSL-enabled sessions instead of having SSLContextFactory load key and trust stores from files. This lets key material held in memory, e.g. delivered by a secrets manager as environment variables, be used without writing it to disk.

Closes #1343. Follows the approach suggested in #678 / discussion #679.

Changes

SSLContextProvider (quickfix.mina.ssl): a functional interface, SSLContext getSSLContext(SSLConfig). The default is SSLContextFactory::getInstance, so existing behaviour is unchanged.
withSSLContextProvider(...) on the builders of SocketInitiator, SocketAcceptor and their threaded variants. Without it (or with null), the builder uses SSLContextFactory::getInstance.
The provider is held in a final, never-null field of AbstractSocketAcceptor / AbstractSocketInitiator, set through new constructor overloads; the existing constructors use the default.
Failure handling: if the provider throws GeneralSecurityException, the session (initiator) or listening address (acceptor) fails to initialize, honouring ContinueInitializationOnError. The provider must not return null. There is no silent fallback to file stores.
Only the SSLContext comes from the provider; protocols, cipher suites, NeedClientAuth, SNI and endpoint identification are still applied from the settings.
User manual: new "Supplying SSL contexts from the application" section in secure_communications.html.

Usage

char[] password = System.getenv("FIX_KEYSTORE_PASSWORD").toCharArray();
KeyStore keyStore = KeyStore.getInstance("PKCS12");
keyStore.load(new ByteArrayInputStream(Base64.getMimeDecoder().decode(System.getenv("FIX_KEYSTORE_B64"))), password);
KeyStore trustStore = KeyStore.getInstance("PKCS12");
trustStore.load(new ByteArrayInputStream(Base64.getMimeDecoder().decode(System.getenv("FIX_TRUSTSTORE_B64"))),
        System.getenv("FIX_TRUSTSTORE_PASSWORD").toCharArray());

KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(keyStore, password);
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(trustStore);
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);

SocketInitiator initiator = SocketInitiator.newBuilder()
        // ... application, store factory, settings
        .withSSLContextProvider(sslConfig -> sslContext)
        .build();

The provider receives the SSLConfig of each session or acceptor address, so it can also return different contexts per session, or delegate to SSLContextFactory.getInstance(sslConfig) for stores that should still be loaded from files.

Compatibility

No behaviour change for existing users; all new API is additive. SSLContextFactory and SessionConnector are unchanged, and connectors created with the existing constructors keep loading stores from files.
The existing package-private IoSessionInitiator constructor is kept and delegates to the new one.
Java 8 compatible, no new dependencies.

Testing

New SSLContextProviderTest:

mutual TLS logon with contexts built from in-memory PKCS12/JCEKS stores, using both the plain and the threaded connector builders;
without a provider, the configured stores are loaded from files as before;
initiator and acceptor start fail when the provider throws GeneralSecurityException;
with ContinueInitializationOnError=Y, a failing provider skips the acceptor address and the initiator session.

Existing SSLCertificateTest, SecureSocketTest, IoSessionInitiatorTest, SocketInitiatorTest and SocketAcceptorTest pass unchanged.

codecov · 2026-10-14T08:17:47Z

Codecov Report

❌ Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.51%. Comparing base (149869e) to head (9774ec4).

Files with missing lines	Patch %	Lines
...quickfix/mina/acceptor/AbstractSocketAcceptor.java	66.66%	2 Missing ⚠️
...ickfix/mina/initiator/AbstractSocketInitiator.java	66.66%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1344      +/-   ##
============================================
+ Coverage     70.79%   71.51%   +0.72%     
- Complexity     2270     2297      +27     
============================================
  Files           161      161              
  Lines          9077     9094      +17     
  Branches       1192     1193       +1     
============================================
+ Hits           6426     6504      +78     
+ Misses         2198     2139      -59     
+ Partials        453      451       -2

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Allow applications to supply the SSLContext for SSL-enabled sessions instead of having SSLContextFactory load stores from files, e.g. when key material is delivered by a secrets manager as environment variables. - Add SSLContextProvider, keyed by SSLConfig; the default is SSLContextFactory::getInstance, so existing behaviour is unchanged. - Add setSSLContextProvider on SessionConnector and withSSLContextProvider on the connector builders. - Report provider failures and null contexts as initialization errors, honouring ContinueInitializationOnError; no fallback to file stores. - Document usage in the secure communications user manual. Relates to quickfix-j#1343, quickfix-j#678

the-thing

Useful feature. Can we just make the field final and if specific provider logic is required can we make it in the builder?

the-thing · 2026-10-14T08:53:11Z

        log.info("Installing SSL filter for {}", descriptor.getAddress());
        SSLConfig sslConfig = descriptor.getSslConfig();
-        SSLContext sslContext = SSLContextFactory.getInstance(sslConfig);
+        SSLContext sslContext = getSSLContextProvider().getSSLContext(sslConfig);


This probably shouldn't be a method, but just a final field that is never null.

the-thing · 2026-10-14T08:54:12Z

            .newSingleThreadScheduledExecutor(new QFTimerThreadFactory());
    private ScheduledFuture<?> sessionTimerFuture;
    private IoFilterChainBuilder ioFilterChainBuilder;
+    private SSLContextProvider sslContextProvider = SSLContextFactory::getInstance;


instead of initializing it like that this should be created via builder pattern.

the-thing · 2026-10-14T08:54:33Z

+    /**
+     * Sets the provider of SSL contexts, or null for the default. Must be set before the connector is started.
+     */
+    public void setSSLContextProvider(SSLContextProvider sslContextProvider) {


Mentioned before. Can we remove it and make the field final?

the-thing · 2026-10-14T08:55:24Z

        @Override
        protected SocketAcceptor doBuild() throws ConfigError {
-            return new SocketAcceptor(this);
+            SocketAcceptor socketAcceptor = new SocketAcceptor(this);


This kinds of break builder pattern. The field should be set to final field in the socket acceptor constructor.

the-thing · 2026-10-14T08:55:35Z

        @Override
        protected SocketInitiator doBuild() throws ConfigError {
-            return new SocketInitiator(this);
+            SocketInitiator socketInitiator = new SocketInitiator(this);


Same here. This method shouldn't change.

the-thing · 2026-10-14T08:55:49Z

        @Override
        protected ThreadedSocketAcceptor doBuild() throws ConfigError {
-            return new ThreadedSocketAcceptor(this);
+            ThreadedSocketAcceptor threadedSocketAcceptor = new ThreadedSocketAcceptor(this);


Here as well.

the-thing · 2026-10-14T08:55:56Z

        @Override
        protected ThreadedSocketInitiator doBuild() throws ConfigError {
-            return new ThreadedSocketInitiator(this);
+            ThreadedSocketInitiator threadedSocketInitiator = new ThreadedSocketInitiator(this);


Address review: remove SessionConnector.setSSLContextProvider and the wrapping getter, keep the provider in a final, never-null field of the socket acceptor and initiator, and pass it through their constructors. The builder defaults the provider to SSLContextFactory::getInstance in build(), like the log and message factories.

nkrivenko · 2026-10-14T09:52:00Z

Hello @the-thing , thank you for your comments, moved everything to builders and made the field final. Could you please review again when you have a chance?

the-thing · 2026-10-14T09:53:31Z

Will do. It might take a few days, but I will. Stay tuned.

the-thing

LGTM.

SSLContextProviderTest start / stop could have been wrapped in separate try / finally blocks.

Not for this PR, but I have a feeling that these overloaded super constructors are too large and probably every one of them should have a single parameter builder and take whatever they need from there.

Give each connector in SSLContextProviderTest its own try/finally, so a failing stop cannot leave the other connector running. Load the trust store in the user manual example with its password: PKCS12 trust stores created by current JDKs encrypt their certificates, so loading them without a password yields an empty trust store.

nkrivenko · 2026-10-16T09:19:14Z

Thank you @the-thing , addressed this comment:

SSLContextProviderTest start / stop could have been wrapped in separate try / finally blocks.

Also will take a look whether we can replace the ctors' parameters with builders, will create an issue for that if this is feasible.

nkrivenko marked this pull request as ready for review October 14, 2026 07:20

nkrivenko added 2 commits October 14, 2026 11:43

Test SSLContextProvider with threaded connector builders and null reset

93736f6

nkrivenko force-pushed the feature/1343-ssl-context-provider branch from d4dd222 to 93736f6 Compare October 14, 2026 08:44

the-thing suggested changes Oct 14, 2026

View reviewed changes

the-thing approved these changes Oct 15, 2026

View reviewed changes

Conversation

nkrivenko commented Oct 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Usage

Compatibility

Testing

Uh oh!

codecov Bot commented Oct 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

the-thing left a comment

Choose a reason for hiding this comment

Uh oh!

the-thing Oct 14, 2026

Choose a reason for hiding this comment

Uh oh!

the-thing Oct 14, 2026

Choose a reason for hiding this comment

Uh oh!

the-thing Oct 14, 2026

Choose a reason for hiding this comment

Uh oh!

the-thing Oct 14, 2026

Choose a reason for hiding this comment

Uh oh!

the-thing Oct 14, 2026

Choose a reason for hiding this comment

Uh oh!

the-thing Oct 14, 2026

Choose a reason for hiding this comment

Uh oh!

the-thing Oct 14, 2026

Choose a reason for hiding this comment

Uh oh!

nkrivenko commented Oct 14, 2026

Uh oh!

the-thing commented Oct 14, 2026

Uh oh!

the-thing left a comment

Choose a reason for hiding this comment

Uh oh!

nkrivenko commented Oct 16, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nkrivenko commented Oct 14, 2026 •

edited

Loading

codecov Bot commented Oct 14, 2026 •

edited

Loading