You have the control components running, but they cannot trust one another yet. This lab uses our own certificate authority on Cisco Catalyst SD-WAN 20.18.2.1 with C8000v on IOS XE 17.18.02, built in my home lab. No Smart Account or PnP Connect signup was used for this certificate workflow.
This is part of the Cisco SD-WAN series. Previous: Validator and Controller initial configuration on SD-WAN 20.18. Next: Uploading the WAN edge serial list manually: the C8000v caveat.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
Separate trust from admission
A certificate authority (CA) signs a device's identity, like an office issuing an access badge. The root certificate lets another device check that signature. The root's private key is the badge-making tool, so it stays on the signing machine.
A signed badge still needs to be on the guest list. SD-WAN also checks the authorized chassis and serial records. We handle that list in the next post.
Enterprise signing changes how certificates are issued. It does not grant image-download rights, a throughput license, or a production entitlement. Pay As You Go (PAYG) is the name of the software-identity feature used later, not a promise that licensing disappears.
Use one root for this isolated fabric
Our root is named PingLabz Lab Root CA, with organization pinglabz-lab. Public certificate metadata checked from the running build shows identical subject and issuer names, which is expected for a self-signed root.
Cisco's certificate-management guide supports enterprise certificates and requires a suitable RSA root key. It also explains that the device certificates and authorized serial list are both required. Keep the fabric's organization settings consistent.
For a new isolated lab, this OpenSSL recipe creates a root. I checked the recipe on disposable local files, separately from the running fabric. Do not run it over an existing root or replace a working fabric's CA as a routine step.
umask 077
openssl req -x509 -newkey rsa:2048 -sha256 -nodes \
-days 3650 -keyout rootCA.key -out rootCA.pem \
-subj '/C=US/ST=CA/L=Lab/O=pinglabz-lab/CN=PingLabz Lab Root CA' \
-addext 'basicConstraints=critical,CA:TRUE' \
-addext 'keyUsage=critical,keyCertSign,cRLSign'This example leaves the private key unencrypted for an isolated lab. Protect the directory, keep it off the routers, and do not reuse it for production. A production CA needs its own key protection, issuance policy, and revocation plan.
Check the public result:
openssl x509 -in rootCA.pem -noout -subject -issuer -datesThe running lab's root expires in November 2036. The ten-year lifetime is a lab choice, not a Cisco recommendation.
Select enterprise signing in the Manager
Use Administration > Settings for the fabric organization and certificate authorization. Cisco documents Enterprise Root Certificate for control components and manual enterprise authorization for virtual WAN edges. Do not leave virtual-edge authorization on a Cisco PKI workflow if your intended signer is this local CA.
Our recorded API configuration set certificateSigning to enterprise and uploaded the public root as enterpriseRootCA. The root private key was never uploaded.
The build also installed the public root directly on the three control components. The control-component CLI command is:
request root-cert-chain install /home/admin/rootCA.pemFor a C8000v edge, after transferring the public file to bootflash, the command differs:
request platform software sdwan root-cert-chain install bootflash:rootCA.pemThe file-transfer casebook covers why old tclsh file-writing examples fail on these edges.
PEM is the Base64-encoded certificate text in a file with BEGIN and END certificate markers. The root certificate file is public. Its private key is a separate file.
Sign the device's own request
A certificate signing request (CSR) is the device asking the CA to sign its public key and identity. Like a completed badge application, it must belong to the device receiving the badge. Do not substitute a generic request with a convenient common name.
The Manager generated the control-component CSRs. Its own request used deviceIP 1.1.1.1. We then downloaded each request, signed it, and installed the returned certificate through the Manager, one device at a time.
Our signing script used this command, with controller replaced by the request's device name:
openssl x509 -req -in controller.csr \
-CA rootCA.pem -CAkey rootCA.key -CAcreateserial \
-out controller.crt -days 2000 -sha256 -copy_extensions copy-copy_extensions copy preserves extensions from the trusted device-generated request. Inspect requests before signing them. Do not apply that command indiscriminately to untrusted requests, especially requests that ask for CA privileges.
Check the resulting certificate:
openssl verify -CAfile rootCA.pem controller.crt
openssl x509 -in controller.crt -noout -subject -issuer -serialThe 2,000-day lifetime matches the lab signing script. Confirm that it fits within the root's validity. OpenSSL verification of a disposable test leaf returned OK; the fabric's separate operational proof is its authenticated control connections.
Install through the Manager and wait
The working sequence installed Manager, Validator, and Controller certificates first. Edge certificates came later, after activation produced their CSRs.
Our API install sent the raw PEM certificate to /dataservice/certificate/install/signedCert, with content type application/json as used by this build. The body was the certificate text, not a JSON string containing it. That endpoint detail is lab-tested behavior, not a general content-type rule.
Do not submit the next installation until the task completes. From 20.18.1, Cisco documents a staging check for edge certificates: the edge first tries the new certificate with the Validator. In the successful run, edge installs took about 70 to 90 seconds.
Verify trust on the edge
This is a fresh, trimmed capture from edge1:
edge1#show sdwan certificate installed | include Issuer:
Issuer: C = US, ST = CA, L = Lab, O = pinglabz-lab, CN = PingLabz Lab Root CAThe root store also contains that root with CA:TRUE. It contains other factory roots too, so seeing several certificates is normal.
Finally, check control connections and OMP. A file named rootCA.pem on bootflash proves only that a file exists. The installed root, the leaf issuer, and authenticated peers together prove that this trust setup is being used.