An older certificate tutorial tells you to open tclsh and paste a PEM file. Your router refuses the command. I reproduced that refusal on C8000v with IOS XE 17.18.02 in a Cisco Catalyst SD-WAN 20.18.2.1 fabric, built in my home lab.
This is part of the Cisco SD-WAN series. Previous: Onboard a Catalyst 8000v 17.18 in controller mode. This is the file-transfer sibling to the onboarding guide. Return to its checks after installing the root. Next: Autonomous vs Controller Mode on IOS XE.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
The symptom is a mode restriction
This is the current router's response:
edge1#tclsh
This command is not supported in Controller mode.The Tool Command Language shell, tclsh, is often used in old IOS examples to create a file from pasted text. On this router, that shell never opens. Retrying the paste or changing the certificate contents will not help.
Controller mode is the router's SD-WAN operating mode. A fresh show version identifies it as Controller-Managed. I left that mode unchanged.
Do not switch the router to autonomous mode just to write a certificate file. That would change the operating environment you are trying to onboard. The task is to deliver a file, and file transfer can do that without opening Tcl.
Separate the root from the device certificate
A root certificate is the list of trusted issuers, like the office that printed an access badge. A device certificate is the individual badge. Copying either file into bootflash does not perform the other operation.
For our enterprise CA workflow, we transferred the public root to each edge and installed it with the root-chain command. Later, after activation, we signed the edge's own certificate request and let the Manager install the resulting device certificate.
Only public certificates move to the edge. The CA's private signing key stays on the signing machine. Do not copy rootCA.key into bootflash as part of a root installation.
Transfer the root instead of writing it in Tcl
The successful lab script used SCP to upload rootCA.pem to bootflash:rootCA.pem. Secure Copy (SCP) transfers a file through an SSH session. It replaces the file-writing step, not the trust check.
Our automation used an SCP upload helper. If you use a workstation client instead, make sure the target supports the protocol that client selects. Current OpenSSH clients commonly use SFTP for scp; scp -O selects the older SCP protocol when needed. That client option is documented behavior, not a fresh test of every workstation and router combination.
A workstation-side example is:
scp -O rootCA.pem <EDGE_USER>@<EDGE_ADDRESS>:bootflash:rootCA.pemSupply credentials interactively or through your approved credential store. The address must be reachable through the management path you configured. The example is not the exact helper invocation used in our capture.
Before installing the file, compare its contents or checksum with the intended public root. Cisco's certificate-management guide requires Base64-encoded certificates, such as PEM, for this workflow. Do not assume a DER file is interchangeable just because it ends in .cer.
Install the root with the SD-WAN command
The working edge bootstrap script ran:
request platform software sdwan root-cert-chain install bootflash:rootCA.pem
show sdwan certificate root-ca-certThe file name after install is the uploaded file. The install command imports the trust chain into the SD-WAN certificate store.
A fresh check of that store shows our lab root. The following lines are excerpts, not the whole store:
Issuer: C = US, ST = CA, L = Lab, O = pinglabz-lab, CN = PingLabz Lab Root CA
Subject: C = US, ST = CA, L = Lab, O = pinglabz-lab, CN = PingLabz Lab Root CA
CA:TRUEThe store also contains factory roots. Finding a familiar Cisco issuer elsewhere in the output does not prove your enterprise root was imported. Match your root's subject and fingerprint.
Keep the device-certificate install in the Manager
The router can also accept a device certificate directly with this command, which we used during an earlier recovery attempt:
request platform software sdwan certificate install bootflash:edge1.crtThat attempt brought connections up, but it did not fix the Manager's stale certificate record. The next authorized-list push revoked the edge. Treat the command as a warning about state consistency, not a shortcut for the normal onboarding procedure.
In the successful rebuild, each device certificate went through the Manager. We waited for certinstalled, compared the certificate serial with the inventory record, and only then sent the final list to the controllers. The onboarding post gives the full sequence.
Verify the installed result
On edge1, show sdwan certificate installed identifies PingLabz Lab Root CA as the leaf certificate's issuer. The same fresh capture shows an Overlay Management Protocol (OMP) peer to 1.1.1.2 and two Bidirectional Forwarding Detection (BFD) sessions to edge2, both up.
Those checks answer separate questions. The root store proves the issuer is trusted. The device certificate output identifies what the router presents. The authenticated control connections prove the fabric accepted it.
If the root is present but the device still fails to join, check the Validator address, organization, certificate dates, and authorized device list. A tclsh failure explains why a file-writing technique did not work. It does not diagnose every later authentication failure.