Keeping TLS trust local to a connection

Connection-scoped trust

The WinTAK integration required connection-specific TLS identities and trust anchors. Installing the supplied certificate authorities into the host store would have extended their trust beyond the application and introduced an additional provisioning requirement.

I implemented custom-root trust within each connection context. Imported bundles provided the identity, intermediates and trust anchors required for peer validation, without modifying the host certificate store.

Identity and trust material

An identity comprises the certificate and private key presented to a peer. A trust bundle supplies the authorities against which the peer's certificate chain is validated. Combined packages may contain both identity and chain material; their contents must be assigned to the appropriate role.

Certificate requirements follow the effective client or server role. A server configured for mutual TLS requires a client certificate. A client identity is optional where the remote server requires only server authentication.

TLS context construction

1. Validate the importCheck bundle purpose, identity key material and certificate usage.
2. Load for the connectionDecrypt the stored bundle and construct the identity and chain material in memory.
3. Validate the peerBuild its chain against the configured roots and apply the connection's certificate policy.
4. Accept or rejectOnly an accepted handshake opens the application-data path.

Trust isolation example

In a synthetic configuration, connection A trusts root Alpha and connection B trusts root Beta. A peer chain rooted in Alpha is eligible for acceptance on A, subject to the remaining certificate checks. It must remain untrusted on B unless Beta also validates that chain.

This test isolates trust configuration between connections. Acceptance also depends on certificate purpose, peer identity and the configured validation policy.

Certificate lifecycle

Imported bundles are encrypted in storage and loaded for the connection lifecycle. Decrypted buffers require controlled retention and cleanup. Protection of stored material does not protect keys from an attacker with equivalent access to the running process.

Certificate rotation requires a defined activation point: updating a stored bundle does not necessarily replace an active TLS context. The application must also retain the key material required to decrypt existing certificate records.

Disconnected deployment affects access to revocation information. Revocation behaviour and any permitted validation exception require explicit, connection-scoped policy and appropriate audit records.

Verification requirements

• Use a valid identity and the intended trust root as the successful baseline.
• Try an untrusted root, an unsuitable certificate purpose and a missing required client identity.
• Exercise the two-connection example so trust does not spread between contexts.
• Verify that a rejected peer leaves the listener ready for the next connection.
• Check teardown and reopening after a bundle change.

The documented socket tests cover TLS delivery and listener resilience. The additional cases listed here are recommended regression checks.

Related reading: connection roles, testing boundaries and the networking rebuild.