In this lesson, we are going to start discussing the SD-WAN topic of Certificates. I have found out that many network engineers do not really understand the basic concepts of online trust, PKI, Certification Authorities, and Certificates. That is why I've decided to make this elementary, high-level lesson that explains each term in plain simple language with lots of funny examples. 

What is Trust?

Let's start with the basics.

In general terms, trust is confidence in or reliance on another person or entity. In networking, trust is to be able to verify whether the software and the hardware that incorporate your network infrastructure are uncompromised, genuine, and functioning as intended.

There are two general types of trust, as illustrated in figure 1 above:

• If one person trusts another person, this is Direct trust.
• If two individuals trust each other, because each trusts a third person or entity, this is Third-Party trust. For example, if you and a colleague that you don't personally know both unquestioningly trust your employer, you trust each other even though you've never met.

Because of the vastness of the Internet and the billions of connected devices, websites, and all kinds of other stuff, the direct trust model simply can't scale that much and is not feasible. That is why, in online communications and the Internet, we use the Third-party trust model. An entity on the Internet (device, website, service, etc.) trusts another one because each one trusts a third-party entity called a Certificate Authority (CA).

In Cisco SD-WAN, devices trust each other because they trust a common Root CA, as shown on the left in figure 2 below. This is typically referred to as the chain-of-trust. 

A device knows which Root CAs it trusts by having an installed root certificate that identifies each root certificate authority (CA), as shown on the right side of figure 2. The root certificate includes the public key of the CA. You will see later in the lesson why this is important.

What is Certificate Authority (CA)? 

A certificate authority (CA), generally referred to as the Root CA, is an organization that verifies the identities of entities (such as devices, websites, emails, etc) and ties them to cryptographic keys through the assignment of digital certificates.

Root Certificates

The CA issues root certificates that are installed on devices and identify the root certificate authority (CA). The key point here is that the root certificates are always self-signed. Therefore, nobody can verify them directly. Root certificates are generally made trustable by other means different than a certificate, such as regulations, public scrutiny, secure distribution, and hardware root of trust modules integrated into devices during manufacturing. For example, Microsoft and Apple distribute their operating systems (Windows and MAC OS) with pre-installed root certificates of all well-known CAs. Cisco ships all SD-WAN devices with pre-installed root-ca-certificates as you can see in the output below.

vEdge-1# show certificate root-ca-cert | in Issuer
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc.
        Issuer: C=US, O=Symantec Corporation, CN=Symantec Trust Services Private SHA256 Root CA
        Issuer: C=US, O=Symantec Corporation, CN=Symantec Trust Services Private SHA256 Root CA
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc.
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc.
        Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc.
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
        Issuer: OU=Arcturus, O=Cisco, CN=Internal Customer Root CA

In use cases where an organization wants to use its own Enterprise CA, the network administrators install an additional root certificate on all devices. 

End-Client Certificates (as a passport)

The client certificate sometimes referred to as an end-entity or subscriber certificate, is like a person's passport. When a person wants to prove his identity to someone, it shows his passport. In the same way, when a device wants to prove its identity to a remote device, it sends its client certificate during the SSL/TLS handshake. The following table makes a funny comparison between a client certificate and a passport.

Imagine that you are at an airport somewhere in a random country in the world. When you want to prove your identity to the border control, you show your passport. The border control will verify your identity if they accept your country's passports and have a tool that can check whether your passport is genuine. However, if you show your passport to someone that doesn't accept your country's passports, it won't verify your identity.

Similar to the example above, when a client initiates an SSL/TLS connection to a server, the client presents its certificate in order to prove its identity. If the server has the public key of the issuer of the client's certificate, it will verify the certificate's signature and trust the client. The example is illustrated in figure 3 below.

Another important aspect of a client certificate is that it cannot issue additional certificates. It is basically the final link in the chain-of-trust.

Certificate Signing Request (CSR)

Ok, at this point you may be wondering how a client gets a certificate.

Generally, a digital certificate applicant, such as a Cisco SD-WAN device, generates a key pair consisting of a public and a private key, along with a certificate signing request (CSR). The CSR is basically a text file that includes the client's identity information such as organization name, country, state, email address, domain name, and so on, along with the client's public key. However, unlike the public key, the client's private key is never shown to Root CA (or anyone else) is kept secure at all cost. The key generation and the CSR are typically done on the client where the certificate will be later on installed.

After the client generates the CSR request, it sends it to a CA (step 1). The root CA double-checks the information and signs the certificate with its private key (step 2). Then it sends the certificate back to the client as shown in step 3 of figure 4 below. The certificate is now digitally signed and each device that has a root-ca-certificate from this CA would be able to verify the signature.

Let's now see how the verification process happens.

Verifying Identity via Certificates

When the client initiates an SSL/TLS secure connection to a remote server, it presents its signed certificate. When the server receives the client's certificate, it checks the Issuer's distinguished name. If the server has the corresponding issuer's root-ca-certificate installed, it can cryptographically verify the client certificate's signature via the Root CA’s public key. Furthermore, the server can use the certificate's public key to confirm that content was sent by a client in possession of the corresponding private key and that the information's integrity (the information has not been altered after the signing). If the server does not have the issuer's root-ca-certificate, it won't be able to verify the identity of this client.

Figure 5 shows an example of this process where a vSmart controller (a client) initiates a secure SSL/TLS connection to a vManage controller (a server).

Notice that in Cisco SD-WAN, devices authenticate mutually in both directions. For example, when forming a DTLS control connection between a vSmart and a vManage controller, the vSmart proves its identity to vManage, as shown in figure 5 above, and then vManage proves its identity to vSmart as shown in figure 6 below.

At this point, you must have a general idea behind the online trust model using third-party trust via certificates. However, I have intentionally simplified something important - In the real world, there is typically one more link in the chain-of-trust between the end client and the CA and that is the Intermediate CA. Let's see why.

Root CA Security is Paramount

As you have seen so far, the security of the root CA's private keys is uttermost important. If a private key gets compromised and falls into bad hands, the entire chain-of-trust gets compromised which could lead to large-scale security breaches.   

That is why the Root CAs store their private keys within data centers with state-of-the-art physical and IT security. This might seem extreme but is absolutely necessary to protect the authenticity of the issued root certificates.