> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # “tclsh not supported in Controller mode”: installing SD-WAN certificates - URL: https://www.pinglabz.com/tclsh-not-supported-controller-mode/ - Published: 2026-11-05T20:34:36.000Z - Updated: 2026-11-06T04:42:26.000Z - Description: C8000v controller mode rejects tclsh. Transfer the public root instead, install it with the SD-WAN root-chain command, and keep device-certificate installation in the Manager so its inventory stays consistent. - Author: Jaime - Tags: SD-WAN, Cisco 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](https://www.pinglabz.com/cisco-sd-wan/). Previous: [Onboard a Catalyst 8000v 17.18 in controller mode](https://www.pinglabz.com/onboard-c8000v-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](https://www.pinglabz.com/controller-mode-ios-xe/). For SD-WAN Manager (formerly vManage) and the other old names, see the [name map](https://www.pinglabz.com/vmanage-vsmart-vbond-names/). ## 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 @:bootflash:rootCA.pem ``` Supply 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-cert ``` The 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:TRUE ``` The 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. [![C8000v refuses tclsh in controller mode; SCP transfers the public root, the root-chain command installs it, and the root store proves trust](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/tclsh-not-supported-controller-mode.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/tclsh-not-supported-controller-mode.png?ref=pinglabz.com) ## 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.crt ``` That 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](https://www.pinglabz.com/onboard-c8000v-controller-mode/) 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.