Operations

Trust Store Management

Roots · Intermediates · Bundles · Drift

SSLNexus can discover and manage public trust anchors on supported Linux and Windows targets, define approved trust bundles, compare desired and observed state, and provision approved roots/intermediates without moving private keys.

What Trust Store Management Does

Use Trust Store Management when you need to manage who your systems trust, not only which identity certificate a service presents. SSLNexus handles public root and intermediate CA certificates only; private keys are not required or accepted.

Object	Purpose
Trust anchor	A public root or intermediate CA certificate imported into SSLNexus.
Trust bundle	An approved set of included anchors plus explicit exclusions.
Assignment	Links a trust bundle to one or more managed Linux or Windows targets.
Observed state	The trust anchors SSLNexus discovers on a target during a trust-store scan.
Provisioning state	Whether the assigned target is compliant, drifting or waiting for its first scan.

Typical Workflow

Open Trust Management in the Client Server.
Import the public root/intermediate certificate in PEM format. Confirm the displayed subject, issuer and SHA-256 fingerprint before saving.
Create a trust bundle and select the anchors that must be trusted. Add explicit excluded fingerprints where an anchor must not be present.
Assign the bundle to the managed Linux or Windows deployment targets that should follow the policy.
Run Discover to read the current target trust store through the target’s existing SSH or WinRM management channel.
Review Compliant, Drift or Pending status and inspect missing required anchors or excluded anchors that are still present.
Run Provision when you are ready to install the approved public anchors, then discover again to verify the result.

Safe exclusions: An excluded anchor is reported as drift wherever it is observed. SSLNexus only removes an excluded anchor automatically when SSLNexus itself previously provisioned that anchor. Operating-system or vendor-managed roots are not silently deleted.

Linux And Windows Targets

Trust discovery and provisioning reuse the same managed-target credentials and remote-management paths already configured for certificate deployment. Linux uses the existing SSH automation path; Windows uses the existing WinRM path. Test the target connection before relying on trust-store discovery or provisioning.

A trust bundle is assigned to a deployment target, so MSP/customer organisation boundaries and existing target access controls continue to apply.

Understand Drift

State	Meaning
Compliant	Every required anchor is observed and no excluded anchor is present.
Drift	One or more required anchors are missing, or an excluded anchor is present.
Pending	The assignment exists but SSLNexus has not yet completed an observed-state discovery for that target.

Use drift as an operational signal rather than assuming an undiscovered or unscanned system is compliant. Re-run discovery after target changes, operating-system updates or manual trust-store maintenance.

Use Dependency & Impact With Trust Anchors

Trust anchors and bundles are connected to the Dependency & Impact view. Select a root/intermediate to see the known bundles, deployment targets and hosts that currently depend on it.

This lets you answer questions such as “Where is this root trusted?” and “What known systems could be affected if we exclude or remove it?” before making a trust-policy change.

Security Boundary

Public certificate material only: Trust Store Management manages root/intermediate public certificates. Never import a CA private key into this feature.

Trust policy remains scoped to the customer organisation. In MSP environments, one organisation cannot view or inherit another organisation’s trust anchors, bundles or observed state.