Line Spacing: 1.15
The deployment architecture implements Juniper Secure Conductor Onboarding (SCO) to fully automate device provisioning and establish a cryptographically validated chain of trust between the Session Smart Routers (SSR), the onboarding Conductor, and the Juniper Mist Cloud. Once connected to the onboarding conductor, the environment is inspected, verified, upgraded, and SVRv2 certificates are distributed so the SSRs are ready for the final move to the appropriate production pod (hybrid - gold).
To eliminate manual workflows, an internally developed orchestration platform named the Mist Controller System (MCS) acts as the central automation engine. The MCS interfaces directly via APIs with internal resource databases, inventory systems, and both the Mist and Conductor API endpoints to pre-provision, authorize, and track the state of deploying nodes.
The hardware and virtual software targets exhibit fundamental differences in how their cryptographic identities are created and validated during initial provisioning:
We use the European Mist for compliance and GDPR reasons, hence all interaction needs to be towards European endpoint URLs. An SSR should have HTTPS access to the following URLs either through the proxy or direct internet:
ep-terminator.mistsys.net (TCP 443)ep-terminator.eu.mist.com (TCP 443)portal.eu.mist.com (TCP 443)redirect.mist.com (TCP 443)software.128technology.com (TCP 443)In preparation for onboarding, a Mist site has to be created. Sites require: Name, Country, Location, and specifically for onboarding through the session smart conductor, the address of the conductor(s) and an onboarding token that will be added during the onboarding process. SSR (clusters) are added to a Mist site, the idea being customers can be given access to specific sites to give them visibility on their installation, based on their RBAC role propagated through a single sign-on managed by SWIFT.
Part of the footprint only has leased line connectivity without internet access. To be able to onboard these devices, we will use a proxy that can be learned through a DHCP option sequence.
For a device reaching out to Mist to end up in the correct organization, hardware devices will be pre-provisioned by Juniper. For software devices, MCS should retrieve a registration code from Mist through the API to be provided to the customer before onboarding through user data / cloud-init templates.
GET /api/v1/msps/{msp_id}/ssr/register_cmd?ttl={time}
Before provisioning the site settings or moving the device, MCS must initialize the dedicated customer site on Mist.
POST /api/v1/orgs/{org_id}/sites
Request Body (JSON):
{
"name": "<site_name>",
"country_code": "<country_code>",
"timezone": "<timezone>",
"address": "<physical_address>"
}
Once the device boots up and connects to Mist, the orchestration layer verifies connectivity and extracts the required keys.
MCS monitors the asset connectivity status via the Mist inventory endpoint. The workflow proceeds only when this API call returns a status of "connected".
GET /api/v1/msps/{msp_id}/inventory/{device_mac}
For software deployments, MCS programmatically retrieves the virtual TPM generated endorsement key from Mist for that specific MAC address.
POST /api/v1/orgs/{org_id}/ssr/export_idtokens
Request Body (JSON):
{
"macs": ["<device_mac>"]
}
The resulting identification token is added directly to the device definition on the secure onboarding conductor. If the deployment is configured as a high-availability cluster, this must be provisioned for both cluster members.
Before the device attempts to connect to the Conductor, MCS configures the Conductor's candidate configuration database and retrieves the secure onboarding token.
POST /api/v1/config/candidate/authority/router
Request Body (JSON):
{
"name": "<router_name>",
"description": "<router_description>"
}
POST /api/v1/config/candidate/authority/router/{router_name}/node
Request Body (JSON):
{
"name": "<node_name>",
"role": "<node_role_primary_or_secondary>",
"onboarding-token": "<extracted_vTPM_token>"
}
POST /api/v1/config/commit
MCS calls this endpoint on the Conductor to generate the token required for the Mist site pairing.
POST /api/v1/onboarding/tokens
Request Body (JSON):
{
"router": "<router_name>",
"node": "<node_name>",
"expiration": "<expiration_timestamp>"
}
The secure onboarding token retrieved from the Conductor is injected into the customer-specific Mist site configuration parameters, along with the onboarding conductor's static IP address.
POST /api/v1/sites/{site_id}/setting
Request Body (JSON):
{
"ssr": {
"conductor_hosts": [
"<conductor_static_ip>"
],
"conductor_token": "<base64_encoded_conductor_token>"
}
}
Finally, the devices on Mist are moved to the predefined site. This immediately results in the edge device dropping its bootstrap state and reaching out to connect to the onboarding conductor.
POST /api/v1/orgs/{org_id}/inventory/reassign
Request Body (JSON):
{
"site_id": "<site_uuid>",
"macs": ["<device_mac>"]
}
Because spoke routers are already onboarded to Mist, they continue to use their mutual TLS credentials for all communication to Mist after onboarding. Hubs do not traverse the automated SCO pipeline and can leverage the manual Registration Code method to start communication to Mist.
The registration token must be retrieved via the Mist API or GUI (Organization -> Inventory -> Adopt WAN Edge -> SSR). This token is entered at the Authority level on the Conductor.
Since this registration code is only used during the initial connection handshake before transitioning entirely to TLS client certificate identification, a long expiration time is acceptable. However, if a Mist registration code expires, any un-onboarded non-SCO node or replaced hardware unit will fail to join Mist until the code is renewed.
The integrated system includes automated periodic background speed testing to sample and verify actual circuit performance lines. Because these checks are forced through the corporate proxy to reach the Mist testing targets, further engineering assessment is required to ensure that proxy latency overhead does not skew the validity of the line speed metrics. Management proxy properties will be locked globally as Static at the Authority layer—rather than using dynamic DHCP "learned" flags—ensuring complete uniformity across the enterprise framework.