Enterprise CA for SDWAN Instances

Enterprise CA for SDWAN Instances

Several options for local CA follow:

• Customer's existing CA infrastructure
  • Microsoft CA is most commonly used within enterprise environments.
• Convenient CA setup for lab testing:
  • XCA
  • TinyCA
  • OpenSSL
• OpenSSL library is part of most Linux distributions by default.
• OpenSSL can be used for certificate generation, signing CSRs, and so on.

If you use subordinate servers, make sure to export and import the full root-ca chain.

For any cloud-based deployments, or deployments where all devices have internet access, you can use the default CA infrastructure from DigiCert or Cisco, which is the easiest way to use certificates, but it relies on an external CA.

If the network has no internet access for all devices, or if an enterprise or service provider prefers it, you can use a local CA, which is also an ideal solution for lab environments.

Generally, if enterprises or service providers already have a production-level CA hierarchy, they might want to use that setup for the SD-WAN infrastructure as well.

Before deployment, it is recommended that you test compatibility with the enterprise CA. Most enterprises use Microsoft CA, which is supported by SD-WAN. Other CA solutions may work but must be tested.

If subordinate CA servers are used, the entire CA chain must be imported.

Certificate Installation Process Steps: 

Similar to a passport, a certificate has information about the owner (in this case, also about a public key that the owner may use) and is signed by an authority that attests to the information.

Passports are signed by governments; certificates are signed by CAs, trusted organizations

A certificate states the following: The CA signing this certificate attests that the public key listed in this certificate belongs to the node with the identification above.

Any other node may use that certificate if the node trusts the same CA.

Step 1: Nodes Get the Root CA Certificate

Validating a peer certificate requires each node to have a copy of the root CA certificate.

In a certificate hierarchy, every node trusts the same CA (root CA).

The first step in the certificate installation process is for the nodes to get the root certificate, as follows:

• The root CA creates and issues a root CA certificate, which all nodes in the network require to validate certificates.
• Distribute the CA root certificate to all nodes to copy the CA root certificate to all controllers.
• Install the CA root certificate on each node.

Previously, you saw how you could perform this process in vManage directly through the GUI by simply uploading or pasting the certificate, or that you could use SCP to manually copy and then install the certificate.

If you are on a version prior to vManage version 18.3, the root CA chain certificate must be installed manually through the CLI on each controller. Since version 18.3, this is no longer a requirement.

Step 2: Nodes Enroll and Get Their Own Certificate

The second step in the certificate installation process is that every node in the network must do the following:

1. Create enrollment information (including its keys).
2. Send enrollment information to the root CA to sign. On the CA, the enrollment information for each node must be verified (to make sure that no fake devices can enroll) and signed. This signature means that “I, the CA, attest: You can trust this node’s certificate; it is a node of our domain.” This attestation is stored in a node certificate.
3. Node certificates contain only public information and can be distributed freely. However, in many cases, a node sends its own certificate to peer nodes. In SD-WAN nodes, certificates are distributed through the vSmart controllers. Therefore, each node has the root certificate of the CA and its own certificate. (Again, nodes might receive other nodes’ certificates directly; the distribution method does not matter.)

Validate Peer Node Certifications

Validation considerations follow:

• Before the two nodes can communicate, each node uses the root certificate to validate the signature of the peer certificate.
• In SD-WAN, this validation happens between controllers and WAN Edge routers, but not between WAN Edge routers directly.

Before the two nodes can communicate, each node must possess the certificate of the peer node. The peer certificate was signed by the same root CA that the node has locally. Therefore, the node uses the root certificate to validate the signature of the peer certificate. If that signature is correct, the node uses the public key included in the peer certificate.

Now both sides have a public key of their peer and can start a secure connection using this key material.

In SD-WAN, WAN Edge routers receive all crypto information from vSmart controllers, so the exchange illustrated in the figure occurs between a WAN Edge router and a vSmart but not between WAN Edge routers directly.

Add vBond and vSmart to vManage

vManage must be aware of the other controllers.

In Configuration > Devices, click Controllers and add the vBond IP address and the username and password for vBond. You can generate the CSR immediately or wait until all controllers have been added.