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

Comments

mohamedreda5511

Fri, 04/09/2021 - 19:04

I have a question that as you mentioned to bring up the control plane the Vsmart and Vbond must have a root certificate (pre installed) and controller certificate so as i understand we’ll use the root certificate (pre-installed) for establishing the DTLS tunnel between and Vmanage (authentication) to exchange the control certificates.then we need to install the controller certificate on Vsmart and Vbond (by one of the 5 options) from the Vmanage to bring them up.is this sequence true or i’m not understanding well ?

In reply to by mohamedreda5511

Ivan.Ivanov

Sat, 04/10/2021 - 19:14

Tnx Mohamed, that's an excellent question!
The pre-installed root certificate identifies the root certificate authority (the Root CA). This is the chain of trust. It tells the device whom to ask for certificate verification. For example, when a remote peer presents its certificate, the device asks the Root CA to verify whether that certificate can be trusted. The root certificate has nothing to do with DTLS/TLS.
DTLS/TLS tunnels are established only if both sides authenticate successfully with their device certificates. Before that, the communication between vManage and the other controllers is done using NETCONF over SSH (TCP 830) authenticating with the username/password of the respective controller.

mohamedreda5511

Sun, 04/11/2021 - 09:57

Thanks Ivan for your response, so as i understand from you the process will be as the below ,

Rynqlo

Mon, 10/18/2021 - 04:12

Hi Ivan,
May I know whether Authorized List or Controller certificates will be validated first?
How does vManage deploy each certificate on the respective controller before the DTLS tunnel is established?

In reply to by Rynqlo

Ivan.Ivanov

Thu, 10/21/2021 - 15:17

Hi Rynqlo,
Honestly, I don't know which one is validated first. However, I think that the order does not matter that much. What really matters is to know that:
- The Authorized List validates that a controller has been explicitly configured by a network administrator.
- The Controller Certificate verifies the controller's identity against the chain of trust.
Before DTLS/TLS tunnels are established with a newly deployed controller, vManage communicates to the controller using NETCONF over SSH (TCP 830), authenticating with the username/password of the respective controller.
Kind regards,
Ivan Ivanov