Customer Relay Guide

Pair a customer-hosted SSLNexus Relay with an MSP, keep CA credentials local and control each vendor through its own channel.

How Outbound Connections Work

The Relay connects to the MSP Client Server. The MSP never initiates an inbound federation connection to the Relay. Enabling the MSP listener makes the MSP reachable; it does not discover customers or grant access automatically.

1. The MSP creates a customer-specific invitation and gives it to the customer securely.
2. The customer pastes it into Vendor Channels → Pair Another MSP. The Relay opens an outbound HTTPS enrollment connection.
3. The Relay generates its channel machine key locally. The MSP returns a client identity certificate after checking the invitation and licence entitlement.
4. After customer policy configuration and activation, the Relay polls the MSP over mutually authenticated TLS. Queued requests arrive in the responses to those outbound polls.
5. The Relay contacts the selected CA, then sends the certificate or rejection back over another outbound request. The MSP acknowledges receipt.

Responses carrying work do not create an inbound connection. No inbound NAT mapping to the customer Relay is required for federation. Local administrator access and CA challenges have separate networking requirements.

MSP Setup

1. Use a valid licence with MSP HUB entitlement. Open MSP HUB as a Hub administrator and create or select the active customer estate.
2. Under Customer Relays, first enable the MSP Relay listener. Set the public HTTPS origin and listener address, save and allow the service to restart.
3. Make that listener reachable from customer networks. For example, use https://msp.example.org:8444 with a listener of 0.0.0.0:8444. These are examples; use your approved hostname and port.
4. Refresh the page, choose the customer estate and enter your MSP display name. Select Create Customer Pairing Invitation.
5. Share the entire JSON invitation securely with the customer's administrator. It contains the endpoint, trust information and a single-use enrollment token. It expires after ten minutes; create another if necessary.

The listener uses the MSP machine TLS identity. Use direct TLS connectivity or a qualified TCP passthrough. A normal HTTP reverse proxy that terminates TLS cannot preserve the required Relay client-certificate session.

Customer Setup

1. Install the supplied Relay binary package inside customer infrastructure. Open its short-lived initial setup URL and create the first named super administrator. Later logins use email, password and optional MFA.
2. Verify the MSP identity and endpoint through your trusted contact before using the invitation. Open Vendor Channels → Pair Another MSP and paste the JSON.
3. Configure a local CA Connector using your CA credentials.
4. Create a Policy And Profile for that vendor: select the connector, permitted domains, maximum SANs, validity, wildcard policy, approval requirement and approved CA trust.
5. Activate the vendor channel. Pairing alone leaves it inactive until you have configured and accepted the customer policy.

CA credentials and channel private keys remain encrypted on the Relay. A single Relay can pair with multiple MSPs, with separate identities, policies and controls.

Issue And Renew Certificates

1. On the MSP Client Server, refresh the selected estate's channels to obtain its channel ID and profile IDs.
2. Within that customer estate, open the deployment target and select Customer SSLNexus Relay as its CA route. Enter the channel ID, profile ID and requested validity in days.
3. Create the certificate through the normal Client Server workflow. If customer approval is required, approve or reject it on the Relay. The same policy applies to renewals.
4. The returned certificate enters the Client Server's existing artifact, deployment, verification and renewal flow. Inspect request history on both sides if work is waiting or fails.

Networking And CA Validation

• Customer Relay: allow outbound HTTPS to each approved MSP listener and the configured CA endpoints.
• MSP: allow inbound access to its dedicated listener from approved customer networks.
• Relay management: restrict local dashboard access to authorised administrators; it is separate from federation.
• ACME HTTP-01: the CA must reach the relevant challenge on public port 80. Outbound-only federation does not remove this requirement. Use a supported DNS-01 or other CA validation method when inbound HTTP validation is unsuitable.

Approvals, Suspension And Offboarding

Customer approvals apply to issuance and renewal when enabled. Rejection returns to the requester as a terminal result. Pending jobs retain their original job and CSR across restart. Deployment retries reuse already issued certificates.

A customer can suspend or revoke one MSP channel without stopping the other vendor channels. MSP estate suspension also blocks that estate's Relay authorisation. Reactivating an estate does not automatically reopen customer channels; the customer explicitly reactivates them. Offboarding is permanent and requires a new pairing.

Expired or missing MSP entitlement blocks new issuance and renewal. The Licence Authority supplies channel-bound entitlement proof; it receives no CSR, customer domain, CA credential or private key through this federation flow.

Troubleshooting

• Pairing unavailable: enable and save the MSP listener first, wait for restart and refresh.
• Invitation refused: check expiry, single-use status, estate activity and MSP entitlement, then obtain a fresh invitation.
• Bootstrap unavailable: check customer outbound routing, MSP listener/firewall and the advertised endpoint.
• No profile IDs: configure the customer's profile and approved trust, activate the channel and refresh MSP channels.
• Approval waiting: review the Relay approvals page; restarting does not bypass approval.
• Upcoming expiry: the Relay overview displays known certificate expiry, not a confirmed renewal schedule.

Customer Relay GuideMSP HUB administration · CA connectors · Security guidance