ENSDWI Part 5: Certificates, Device Lists, and Control-Plane Troubleshooting

13 July 2026 Cisco ENSDWI SDWAN

Everything in Catalyst SD-WAN authenticates with certificates, so when a fabric won’t come up, the answer is nearly always in the trust chain or the transport between the pieces. This part covers blueprint 2.3 (configure certificates and device lists) and 2.4 (troubleshoot control plane connectivity) — the most exhibit-heavy corner of the Controller Deployment domain.

2.3 Certificates and device lists

The trust model in one diagram’s worth of words

Every controller and every edge holds a device certificate signed by a root CA that everything else trusts. Control connections are mutual TLS/DTLS: both ends present certificates, both ends validate three things — signature chains to a trusted root, organization-name matches, and serial is authorized. Fail any one and the connection dies with a reason code (below).

Root CA options for controllers

Three ways to sign controller certificates — know all three and when each fits:

Cisco PKI (automated) — the modern default. vManage has your Smart Account credentials; CSRs are submitted to Cisco’s CA and returned automatically. Zero manual handling.
Symantec/DigiCert (legacy manual) — the original process: generate CSR per controller in vManage, submit to DigiCert, paste the signed cert back. Appears in older material and still in blueprint scope as the manual flow.
Enterprise CA — your own root: install your root chain on all controllers, sign controller CSRs yourself. Required for air-gapped/on-prem-everything deployments. You own renewal.

Flow, whichever CA: set org-name and vBond on all controllers → vManage generates CSRs (its own, and for vSmart/vBond once they’re added as devices) → certs signed and installed → vManage pushes the root chain and controller list around the fabric via vBond.

WAN Edge identity

Hardware cEdge/vEdge: identity is burned in at manufacture — SUDI (Secure Unique Device Identifier) in TPM/Trust Anchor module on cEdge, factory device certificate on vEdge. Nothing to install; the box proves itself.
Virtual edges (C8000V, vEdge Cloud): no factory identity. They receive a certificate during onboarding — bootstrap config carries a one-time token (OTP), device presents it, vManage signs.

The authorized device list

A valid certificate is necessary, not sufficient — the device’s chassis/serial must be in the authorized WAN Edge list:

Sourced from PnP Connect (Smart Account) as the provisioning file, or uploaded manually (serialFile.viptela), or synced directly when vManage has Smart Account credentials.
vManage distributes the list to all controllers (that’s why vBond can reject an unknown edge at first contact).
Per-device state: valid / staging / invalid. Staging is the exam-favourite: the edge forms control connections (so you can configure and stage it) but data-plane tunnels stay down. Flip to valid to go live. Invalid = rejected entirely.
Decommissioning a compromised edge = mark invalid (and for virtual edges, request vedge-cloud decommission on the instance).

vSmart/vBond also validate each other and edges against the controller authorized list vManage maintains — controllers are added explicitly in vManage, which is why a vSmart you forgot to add never joins, certificate or not.

2.4 Troubleshooting control-plane connectivity

The systematic flow. Exhibits will show one of these outputs with something wrong; work the chain in order.

Step 1: what state are the connections in?

Edge# show sdwan control connections

Healthy = one line per controller per expected transport, state up. Missing lines or connect-state loops mean form-up is failing — go to step 2.

Step 2: why are attempts failing?

Edge# show sdwan control connection-history

The LOCAL/REMOTE ERROR columns carry reason codes. The ones ENSDWI expects you to translate:

Code	Meaning	Usual cause
`DCONFAIL`	DTLS connection failure	Transport/firewall blocking UDP 12346+ — reachability, not certs
`CRTVERFL`	Certificate verification failure	Wrong/expired cert, root chain missing, org-name mismatch
`SERNTPRES`	Serial not present	Device not in the authorized list, or list not synced to that controller
`VB_TMO / VM_TMO / VS_TMO`	Timeout to vBond/vManage/vSmart	Address unreachable, DNS wrong, controller down
`BIDNTVRFD`	Board-ID not verified	Identity/cert problem on the edge itself

DCONFAIL vs CRTVERFL discrimination is the single most-tested skill here: DCONFAIL = network path problem; CRTVERFL = trust problem.

Step 3: check local identity and transport properties

Edge# show sdwan control local-properties

Read top-to-bottom: certificate-status Installed, certificate-validity Valid, organization-name (exact match?), dns-name (vBond address right?), system-ip / site-id set, and the per-interface table at the bottom — each TLOC’s public/private IP:port pairs, NAT type detected, and whether the interface is attempting control (vbond column, max-control-connections).

Step 4: underlay reachability

Boring but tested: can VPN 0 actually reach the controller?

Edge# ping vrf 65528 <vbond-ip>          ! IOS-XE transport VRF ping (or: ping sdwan vpn 0)
Edge# show sdwan omp peers               ! if control is up but routes missing, OMP layer next

DNS for the vBond name, default route in VPN 0, and upstream ACLs/firewalls (UDP 12346-12446 out, return traffic in) round out the checklist. Remember port-hopping from Part 4: a middlebox that lets the first attempt through but breaks the flow shows as connections flapping across ports.

Step 5: controller-side confirmation

vBond# show orchestrator connections            ! who's reached vBond, and in what state
vManage# show control connections               ! vManage's view
vSmart# show control connections

If the edge appears at vBond but never at vSmart, vBond validated it but the vSmart list/reachability is the problem (are the vSmart TLOCs NATed correctly? is the edge’s max-control-connections 0 on the only working transport?).

The worked failure everyone should rehearse

Symptom: new edge, control connections cycling. connection-history shows CRTVERFL from the remote end. local-properties shows org-name ACME-SDWAN — but the controllers were built with Acme-SDWAN. Case-sensitive exact match required → fix org-name on the edge, connections form. Every element of that scenario (the code, the command, the case-sensitivity) is independently a test point.

Certificate operations you configure (not just describe)

Blueprint 2.3 says configure, so know where these live in vManage:

Configuration → Certificates → WAN Edge List: upload/sync the serial file, set valid/staging/invalid, send to controllers.
Configuration → Certificates → Controllers: view/generate CSRs, install signed certs.
Administration → Settings: org-name, vBond address, certificate authorization mode (automated Cisco PKI vs manual vs enterprise root chain upload).
Edge cert renewal is automatic (vManage re-signs before expiry); controller cert expiry is on you — an expired vSmart certificate takes the overlay’s policy/routing updates down with it, so alarm on expiry dates (Part 12 covers the alarm).

Exam traps for this domain

Staging state: control up, data plane down. It exists so you can pre-provision safely.
Serial file comes from PnP Connect / Smart Account (or manual upload) — not generated by vManage.
DCONFAIL = reachability, CRTVERFL = trust, SERNTPRES = list. Translate on sight.
Org-name is case-sensitive and must match everywhere — controllers and edges.
Hardware edges carry SUDI/factory identity; virtual edges get certs via OTP at onboarding.
vBond sees everything first: an edge absent even from show orchestrator connections has an underlay problem, not a certificate problem.

That closes domain 2.0. Part 6 opens Router Deployment (20%): getting real edges onboarded with ZTP, PnP and bootstrap, DC and regional-hub design, TLOC extension, and the underlay/overlay connectivity patterns.