How SSLNexus Connects Its Certificate Infrastructure

SSLNexus brings certificate lifecycle management, customer accounts and licence validation together through separate services with distinct responsibilities. The Client Server manages the certificate estate inside customer infrastructure. The Client Area handles account and licence workflows. The Licence Authority validates entitlements and coordinates authorised service relationships.

The Suite At A Glance

Separate Channels, Explicit Identity

Mutual TLS authenticates both ends of a service connection. Signed evidence binds an authorised operation or relationship to its intended identity. They solve different parts of the trust problem. The service protections above are specific to each channel; the Client Server does not require every deployment target to implement a proprietary SSLNexus protocol.

Sign In From The Engine To The Client Area

The Client Server is the certificate-management engine. An organisation administrator can choose Open Client Area from its About page to obtain a one-time portal sign-in link. The Client Server session and the Client Area session are separate.

1. The Client Server sends the administrator’s email and display name, installation identity, device fingerprint and signed licence credential to the Licence Authority over HTTPS. This sign-in request sends no administrator password, password verifier, certificate private key or CA credential.
2. The Licence Authority validates the licence and installation, then resolves the customer’s Client Area organisation. For a Trial, the verified Trial account determines the customer identity; an authorised first visit can create the missing Client Area organisation.
3. The Licence Authority requests an account link from the Client Area’s private control service over TLS 1.3 with mutual certificate authentication. The Client Area resolves the account and organisation membership and stores a hash of a random sign-in code with a five-minute expiry.
4. The browser opens the Client Area HTTPS account-link page with the code in the URL fragment. The page clears the fragment and submits the code to the Client Area. The Client Area checks expiry and previous use, consumes the code once and issues its own account session.

The link grants access to the mapped Client Area account and organisation. Licence validation and organisation permissions still apply. An expired or previously used link is rejected; request a new link from the Client Server or use the Client Area’s normal sign-in page. This account-link flow is separate from the Client Server’s configurable OIDC sign-in through an organisation’s identity provider.

Which Interfaces Share Data?

SSLNexus uses service-owned data stores. The Client Server, Client Area and Licence Authority each have their own PostgreSQL connection and application records. They exchange authorised requests and customer identifiers through service APIs; the account-link flow does not depend on a shared database between these three services.

Separate channels provide distinct connection identities and access rules. They do not imply a separate database for every listener or customer. Organisation and role checks restrict access to records within each service. Central account and licence records do not include customer certificate private keys or CA credentials.

Signed Evidence And Channel Isolation

Licence credentials and Authority federation assertions use Ed25519 signatures. Federation assertions bind the licence, installation, channel, audience, machine-key fingerprint and nonce, and expire after a short lifetime. The receiver validates the signature and the expected bindings before accepting the assertion. A valid assertion for one customer connection cannot simply be reused as authority for another channel.

Pairing establishes the machine relationship. Customer policy, approval and a current MSP entitlement separately authorise certificate operations. Customer organisation mapping and role checks also apply to portal requests, ticket conversations and attachments. Cryptographic identity complements these application permissions.

Operating SSLNexus With SSLNexus

A CLM provider should use the same lifecycle disciplines for its own services that it provides to customers. The suite supports managing its service hostnames as an SSLNexus certificate estate: public website and portal frontends, the Licence Authority frontend, and the local Client Server frontend. Each service has its own certificate identity, deployment binding and verification path.

1. Record the service hostname, owner, CA adapter and deployment destination.
2. Issue or renew through the configured authority and apply the certificate to its saved binding.
3. Verify the presented certificate and service health after deployment.
4. Track expiry, renewal outcomes and ownership through inventory, monitoring, reports and audit history.

Public-facing HTTPS certificates and private machine-identity certificates serve different audiences. Keep their trust roots and renewal responsibilities distinct. For the local Client Server, its configured control-plane hostname selects the local frontend deployment path. A deployment target connected by IP can carry a separate reporting hostname while its connection address remains the IP.

This describes the suite’s supported architecture and operating model. A deployment’s inventory and verification records establish which endpoints it currently manages.

Customer Keys Stay Local

The central licence and account services do not require customer certificate private keys or CA credentials. Depending on the adapter, keys are generated and retained on the destination, or stored inside the customer’s Client Server. Optional local keystore encryption protects stored certificate artifacts using a protected same-host unlock key. Customer-hosted authority connections retain CA credentials locally.

See Customer authority federation, Deployment targets, Security and the Private Key Policy for operating requirements.