Cisco SD-WAN is designed with the highest level of security in mind. Part of the security stack of the solution is the authentication and authorization of components. Basically, before establishing a control-plane connection, each component must authenticate to each other using their signed certificate, which is validated against the specified chain of trust. The idea is visualized in figure 1 below.

Cisco SD-WAN Establishing Trust
Figuer 1. Cisco SD-WAN Establishing Trust

Controllers Identity

Cisco SD-WAN Controllers can not be brought into operation unless their identity is validated by an established chain of trust. This identity validation process is intended to ensure that only trusted devices can join the SD-WAN solution while still retaining flexibility. Each controller must have a root certificate installed and a controller certificate installed and signed by a trusted CA (Certification Authority). Depending on the deployment method, the chain of trust may be defined in the following manner:

  • In cloud and managed deployments, the root certificate chains might be pre-loaded or automatically installed.
  • In on-prem deployments, the root certificate is retrieved from an Enterprise CA that can be OpenSSL, Cisco ISE, AWS Certificate Manager, or another private CA option.

For the controller certificates, a CSR (Certificate Signing Request) is generated for every controller through the vManage GUI. Then each certificate request is submitted either automatically or manually to the certification authority. After the certification is signed, it is downloaded and installed on the respective controller. There are several different methods to obtain and install a controller certificate:

1. Automated certificate deployment using Cisco PKI: This is the recommended method according to Cisco's documentation. A network administrator generates a CSR for each SD-WAN controller. The CSR is then automatically sent to Cisco's Public Key Infrastructure.  When the CSRs are signed, vManage automatically downloads each signed certificate and installs it on the respective SD-WAN controller. Note that the root certificate that defines the chain of trust is pre-loaded by default on each SD-WAN controller. This method requires vManage version 19.1 or higher.

Automated Certificate signing using Cisco PKI
Figure 2. Automated Certificate signing using Cisco PKI

2.  Automated certificate deployment using 3rd-party CA: A network administrator generates a CSR for each SD-WAN controller. The CSR is then automatically sent to the Symantec/Digicert PKI. The difference here is that a Cisco TAC case needs to be submitted in order to complete the certificate signing process. Once the certs are signed, vManage automatically downloads each one and deploys it on the respective SD-WAN controller. Note that again the root certificate that defines the chain of trust is pre-loaded by default on each device.

Automated Certificate signing using 3rd-party CA
Figure 3. Automated Certificate signing using 3rd-party CA

3. Manual Cisco PKI certificate signing: This option is similar to the automated certificate deployment using Cisco PKI with the only difference that the CSRs are downloaded locally and manually submitted for signing. After the certs are signed, they are downloaded locally and upload manually to vManage. Once that is completed, vManage deploys each cert on the respective controller. Note that again the root certificate that defines the chain of trust is pre-loaded by default on each device.

Manual Certificate signing using Cisco PKI
Figure 4. Manual Certificate signing using Cisco PKI

4. Manual third-party certificate signing through Symantec/Digicert: This option is similar to the automated certificate deployment using 3rd-party CA with the only difference that the CSRs are downloaded locally and manually submitted for signing. A Cisco TAC case needs to be opened in order to complete the certificate signing process. After the certs are signed, they are downloaded locally and upload manually to vManage. Once that is completed, vManage deploys each cert on the respective controller. Note that again the root certificate that defines the chain of trust is pre-loaded by default on each device.

Manual Certificate signing using 3rd-party CA
Figure 5. Manual Certificate signing using 3rd-party CA

5. Enterprise Root Certificate Authority (CA): Of course, Cisco SD-WAN provides the flexibility to enterprises to use their private PKI infrastructure and sign controller certs with their own CA. This method requires the most manual steps comparing to the other available options. The first one is to install the Enterprise CA root certificate on vManage, vManage then automatically distributes this root cert to the other configured controllers. This process is visualized with the black lines in figure 6. A network administrator then generates the CSRs and makes a request for each controller to the Enterprise Root CA. This process is visualized with the blue lines in the figure below. Once the certificates are signed, they are manually uploaded to vManage. vManage will then deploy each certificate on the respective controller. This is visualized with the green lines.

Manual Certificate signing using Enterprise CA
Figure 6. Manual Certificate signing using Enterprise CA

Controller Whitelisting

Cisco SD-WAN employs a whitelisting approach when it comes to adding new controllers into the solution domain. When a network administrator configures a new control device through the vManage GUI, it is automatically added to an authorized list that includes certificate serial numbers of all controllers. This list is then distributed by vManage to all other control-plane devices within the domain. Before establishing control-plane tunnels with each other, the controllers always check whether the remote node's parameters against the authorized whitelist. This technique prevents rouge unauthorized controllers from joining the solution and pushing unapproved configs. However, note that vBond is not checked against the authorized list, but all devices are explicitly configured with the vBond IP address so it basically achieves the same goal.

Controllers Whitelisting
Figure 7. Controllers Whitelisting