You signed a certificate, yet the edge still gets rejected. The control components also need its authorized chassis and serial record. This is the manual path we used on Cisco Catalyst SD-WAN 20.18.2.1 with C8000v on IOS XE 17.18.02, built in my home lab.
This is part of the Cisco SD-WAN series. Previous: Enterprise root CA for Cisco SD-WAN without a Smart Account. Next: Onboard a Catalyst 8000v 17.18 in controller mode.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
A trusted certificate still needs an allowed identity
The certificate is the badge. The WAN edge list is the guest list. A valid signature says who issued the badge, while the list says whether this particular device belongs in the fabric.
A software chassis identity is different from a certificate serial number. The chassis identifies the virtual router. During bootstrap, the Manager also holds an activation token, which is a secret used to get the device started. After certificate installation, the record needs the certificate's actual serial number.
Do not publish a WAN edge export without checking it. Before installation, a field named serialNumber can contain the activation token.
What “manual upload” means here
Cisco's documented conventional workflow accepts an authorized serial file obtained through Plug and Play (PnP), then sends the validated device records to the controllers. PnP Connect can synchronize that inventory with the Manager.
We did not use PnP Connect, create a cloud account, or obtain a file from that portal. We created C8000v software identities locally using the Manager's PAYG function, then pushed the resulting authorized list manually.
That distinction matters to the procedure: there was no successful C8000v CSV file upload in this lab. The manual generation and push path below is what worked.
The CSV attempt that failed
Our notes record a CSV with this header:
Chassis Number,Serial No,Subject Serial No,Hostname,Site Id,System IPThe Manager parsed it but rejected the virtual-platform rows:
Virtual Platform is not allowed in CSV Upload.Treat that as the result for this C8000v workflow and release. It does not establish that every authorized-file format or hardware import is unsupported. I would not keep editing that CSV to solve a virtual identity problem.
Create the two software identities locally
In an authenticated Manager API session, the successful build sent this JSON request:
POST /dataservice/system/device/generate-payg
Content-Type: application/json
{"numPaygDevices":2,"validity":"valid","organization":"pinglabz-lab"}The recorded response was:
Number of PAYG devices added successfully: 2This is a write operation. Run it once for the number of identities you need, then inspect the result before repeating it. Multipart and form requests returned 415 in our notes.
GET /dataservice/system/device/vedges then showed generated C8K-PAYG-... chassis identities in state tokengenerated. At that stage, its serialNumber field held the token. Keep both the chassis and token private and use placeholders in logs shared outside the lab.
PAYG stands for Pay As You Go. The command's existence does not make this a licensing bypass. This post documents an onboarding result on our software lab, not a grant of entitlement.
Send the initial list before activation
The build explicitly pushed the generated records:
POST /dataservice/certificate/vedge/list?action=push
{}The request returned a task ID. We polled GET /dataservice/device/action/status/<TASK_ID> and waited for completion before activating an edge.
The equivalent control in Cisco's documented certificate workflow is Send to Controllers on Configuration > Certificates > WAN Edge List. That button distributes the validated records. Our tested path used the API request above.
This initial push is intentional even though the identities are still awaiting certificates. The Validator needs the bootstrap identity before the edge can present its token.
Finish each certificate before the final push
The next post activates the edge and signs its certificate signing request (CSR). The order matters:
- Activate one edge with its own chassis and token.
- Wait for its CSR in the Manager.
- Sign the request and install the signed certificate through the Manager.
- Wait for
certinstalled. - Compare the Manager's
serialNumberagainst the certificate's serial. - Repeat for the second edge, then push the list again.
The serial check uses the signed public certificate, not the old token:
openssl x509 -in edge1.crt -noout -serialOur script stopped if that value differed from the Manager record. Do not send the final list as a way to repair a stale certificate record.
Why the second push needs a check
An earlier install task stuck while the Manager was unstable. Installing a certificate directly on the edge got connections up temporarily, but the Manager retained a failed install state and the token in its serial field.
The next list push then revoked that edge. The successful run avoided the mismatch by keeping the Manager stable, installing one edge at a time, and checking the actual serial before the final push.
This is a reason to distinguish the initial bootstrap push from the final certificate-backed push. “Never push while a token exists” would be wrong for the first step. “Push again after any certificate attempt” was unsafe in our failed run.
Verify at both ends
On the Validator, inspect show orchestrator valid-vedges to confirm the authorized records. Do not copy its full output into a public post. Check the corresponding certificate state in the Manager.
Then use show sdwan control connections on the edge. After onboarding, our edges reached the Controller and formed OMP peers. A fresh Controller capture shows 10.0.0.1 and 10.0.0.2 both up.
PnP would supply or synchronize inventory in a conventional deployment. Our manual path supplied those records locally and explicitly distributed them. Neither operation replaces root trust or the device certificate installation.