Welcome to the second article of the four-part series about VPN technologies. In the previous article,we discussed fundamental concepts of the IPsec technologies such as the symmetric and asymmetric encryption algorithms, the hashing process, the IPsec protocol suite that includes IKE, ESP and AH protocols, and we have implemented an IPsec VPN site-to-site tunnel using PSK (pre-shared key as authentication method between VPN peers) on ISR routers, explaining every single configuration step and how all the mentioned IPsec technologies fit together to create a secure VPN tunnel. Please make sure you have clearly understood the content of part 1, because all the series articles are logically linked.
Now that we know the necessary IPsec notions, we can move forward by configuring an IPsec VPN site-to-site tunnel using digital certificates: in fact this will be the main purpose of the article.
Digital certificate is another available authentication method (as opposed to PSK) to successfully validate the identity of VPN peers before establishing an IPsec tunnel in order to avoid spoofing of identity (recalling from Part 1 that the 4 VPN benefits are authentication, confidentiality, integrity, and antireply). They are commonly used in VPN networks composed of a high number of peers because they scale pretty well compared to PSK.
VPN IPsec Site-to-Site Tunnel Configuration on a Single Peer
There are five required steps to create an IPsec VPN site-to-site tunnel using Digital Certificates on an ISR router:
Configure ISAKMP/IKE phase 1 policy, which lists all the parameters needed to establish a bidirectional ISAKMP/IKE SA (Security Association) such as the authentication type used by the two peers to authenticate each other (in this case Digital Certificate), Diffie-Hellman group, encryption type, hashing method, ISAKMP exchange mode (main or aggressive, where main is the default), and the tunnel lifetime.
Dario_ISR(config)#crypto isakmp policy 10
Dario_ISR(config-isakmp)#encryption aes 256
- Configure IPsec phase 2 transform-set, where the ESP encapsulation protocol is specified along the encryption type and hashing method in order to create an IPsec SA. At this point, it is possible to set up which mode ESP protocol uses between transport and tunnel, transport is the default.
Dario_ISR(config)#crypto ipsec transform-set INTENSE_SCHOOL_IPSEC esp-aes esp-sha-hmac
- Define the source and destination of traffic (encrypted) that will take part in the tunnel by configuring an extended access list.
Dario_ISR(config)#access-list 120 permit ip 192.168.10.0 0.0.0.255 10.10.10.0 0.0.0.255
- Configure a crypto-map where the peer IP address is set, the transform-set configured at point 3 is recalled, and the access list which defines the interesting traffic is applied.
Dario_ISR(config)#crypto map INTENSE_SCHOOL_MAP 1 ipsec-isakmp
Dario_ISR(config-crypto-map)#set peer 126.96.36.199
Dario_ISR(config-crypto-map)#set transform-set INTENSE_SCHOOL_IPSEC
Dario_ISR(config-crypto-map)#match address 110
- Apply the crypto-map to the interface that will be used to build the IPsec VPN tunnel.
Dario_ISR(config-if)#crypto map INTENSE_SCHOOL_MAP
Figure 1: IPsec site-to-site with digital certificate in ISR router peer sample configuration
You should know already the definitions and the functions of all the above steps that are part of the IPsec site-to-site tunnel configuration, as it has been extensively explained on the CCNA SEC Prep: VPN Technologies (Part 1) article.
The only difference is the digital certificate method used for the VPN peers to authenticate each other which has been issued with the command authentication rsa-sig within the crypto isakmp policy 10. RSA is an asymmetric encryption algorithm and the certificate signature algorithm in our example.
We are now going to explain the theory behind this authentication mode.
PKI (Public Key Infrastructure)
PKI is the service framework, which consists of the hardware, software, people, policies, and procedures necessary to generate, manage, distribute, store, and revoke digital certificates. A PKI allows for very scalable solutions and it is an extremely important authentication solution for VPNs. PKI enables large-scale use of public key cryptography to provide authenticity, confidentiality, integrity, and non-repudiation services.
Two very important terms must be defined when talking about a PKI: Certificates and certificate authority (CA).
A certificate is an electronic document that uses a digital signature to bind an identity, such as a name or an organization, with a public key. Certificaters are usually published in a centralized directory so that other PKI users can easily access them. They are used for various purposes in a network.
The CA is a trusted third-party entity that issues certificates. The certificate of a subject is always signed by a CA. Every CA also has a certificate containing its public key, signed by itself. This is called a CA certificate.
A certificate authority is an entity that creates and issues digital certificates. Digital certificate contains information about the identity of a device. An overall explanation of all the info included into the certificate is reported on the paragraph “X.500 and X509v3 Certificates.” The CA takes requests from devices that supply all information by generating a CSR (CSR includes the public key generated by the computer or network devices who is making the request) and, based on the content of the CSR, it generates a digital certificate, to which the CA assigns an unique serial number and signs the certificate with its own digital signature (the CA’s signature). Also included in the final certificate are an URL that other devices can check to see whether this certificate has been revoked (CRL) and the validity dates for the certificate. The certificate includes information about the CA that issued the certificate and several other parameters used by PKI.
One benefit of using a commercial CA server to obtain digital certificates for your devices is that most web browsers maintain a list of the more common trusted public CA servers and, as a result, anyone using a browser can verify the identity of a web server by default without having to modify the web browser at all. If a company wants to set up their own internal CA and then configure each of the end devices to trust the certificates issued by their internal CA, no commercial certificate authority is required, but the scope of that CA is limited to the company and its managed devices, because any devices outside of the company would not trust the company’s internal CA by default.
A digital certificate can be thought of as an electronic document that identifies a device or a person. It includes information such as the name of a person or organization, their address, and the public key of that person or that device. There are different types of certificates, including root certificates (which identify the CA), and identity certificates which identify devices such as VPN peers and others devices that want to participate in PKI.
There are two types of digital certificates:
- * Root certificate
- * Identify certificate
A root certificate contains the public key of the CA server and the other details about the CA server. An identity certificate is similar to a root certificate, but it describes the client and contains the public key of an individual host (the client). An example of a client is a web server that wants to support secure sockets layer (SSL) or a router that wants to use digital signatures for peer authentication on a VPN tunnel.
Therefore both certificates, root and identity, are fundamental to verify the identity of an unknown peer. In fact, you can find list of root CA certificates in any web browser (as HTTP over SSL protocol, HTTPS, requires the exchange of certificate between the client browser and web server to authenticate the web server identity). So what really happens is that the client receives a digital certificate from the server that contains the server public key and the client verifies the CA digital signature within the server certificate by looking into the browser CA certificate store, where the client retrieves the CA digital signature and, if it matches with the one contained in the server certificate, we can trust the server identity and, most important, its public key. The same process occurs for the server to verify the client identity. Now that client and server trust and have each other’s public keys, they can use those keys to verify each other’s digital signatures (Key functionalities of digital signatures are explained below on the paragraph “Digital Signatures”).
And the same process occurs when two VPN peers authenticate themselves during the establishment of a VPN IPsec tunnel. Don’t forget that the VPN peer authentication happens during the IKE phase 1 (ISAKMP).
The key concept here is that the identify certificate is trusted by a well-known third party CA (through the comparison of CA digital signature within the identity certificate and the CA digital signature on the CA certificate store) and we all trust the CA entities!
X.500 and X.509v3 Certificates
X.500 is a standard that describes the certificate structure and format. It is used in different applications, such as securing web servers using SSL and TLS, securing emails using SMTP over SSL, securing LDAP queries over TLS or SSL, and IPsec VPNs.
This X.500 structure is the foundation from which you see common directory elements like common name, organizational unit, organization, and so on in an “org-chart” way, shaped like a pyramid. X.509 Version 3 is a standard for digital certificates that is widely accepted and that incorporates many of the same directory and naming standards. A common protocol that is used to do lookups from a directory is called lightweight directory access protocol (LDAP). A common use for this is having a digital certificate being used for authentication, and then based on the details for that certificate (for example, the OU field in the certificate itself), the user could be dynamically assigned the access rights that are associated with that group in the active directory or some other LDAP accessible database.
Most digital certificates contain the following information:
- * Serial number—Assigned by the CA and used to uniquely identify the certificate;
- * Subject—The person or entity that is being identified;
- * Signature algorithm—The specific algorithm that was used for signing the digital certificate, in our case RSA asymmetric algorithm;
- * Signature—The digital signature from the certificate authority (CA), which is used by devices that want to verify the authenticity of the certificate issued by that CA;
- * Issuer—The entity or CA that created and issued the digital certificate;
- * Valid from—The date the certificate became valid;
- * Valid to—The expiration date of the certificate;
- * Key usage—The functions for which the public key in the certificate may be used;
- * Public key—The public portion of the public and private key pair generated by the host whose certificate is being looked at;
- * Thumbprint algorithm—The hash algorithm used for data integrity;
- * Thumbprint—The actual hash;
- * Certificate revocation list location—The URL that can be checked to see whether the serial numbers of any certificates issued by the CA have been revoked.
Figure 2: Sample of a CA root certificate taken from IE browser certification store
The digital signature is one of the most important parts of a digital certificate because, as we said, it binds a subject identity to a public key. We are already in the phase where a client and a server or 2 VPN peers trust each other’s public keys therefore they trust each other identities (concept explained in the Digital Certificate paragraph).
IPsec peers use digital signatures to authenticate their internet key exchange (IKE) sessions through a process which involves hash function and asymmetric encryption algorithm (RSA in our case, don’t forget the issued command authentication rsa-sig within the crypto isakmp policy 10).
There are six steps to the digital signature process:
1. The sending device creates a hash of the document called digest.
2. The sending device encrypts the digest with the private key of the signer.
3. The encrypted hash, known as the signature, is appended to the document.
4. The receiving device accepts the document with the digital signature and it has already the public key of the sending device.
5. The receiving device decrypts the signature using the public key of the sending device having as a result the original digest.
6. The receiving device makes a hash of the received document, without its signature, and compares this digest to the decrypted signature hash obtained on point 5. If the hashes match, the document is authentic and it is has not been tampered with; it was signed by the assumed signer and has not changed since it was signed.
The digital signature process and its core benefits, authentication, integrity and non-repudiation are explained in Figure 3:
Figure 3: Digital signature process and its three core benefits
Enroll with a CA and Become a Member of PKI
The process of adding a CA root certificate is easy. By default, the ISR router or the ASA firewall has no default CA root certificates installed. So, before you add an identity certificate, you first need to add the certificate of the issuing CA from which you purchase your certificate. When the CA issues an identity certificate, it usually sends the certificates of their root CA to add as well. If you don’t have a copy, you can easily locate and download it from the CA’s website.
Now the indentify certificate issued by the CA must be installed on the router or on the ASA. First a CSR (certificate signing request) must be created for the purposes of sending to a CA for signing. This procedure is standard and it is the same for any CA. Creating a CSR requires filling out some mandatory fields that will characterize the final X.509 identity certificate properties. Consequently an output contained between the —-BEGIN CERTIFICATE REQUEST— and —-END CERTIFICATE REQUEST—- is generated by the router once filled a CSR. This must be saved on a text editor and sent to the CA for certificate generation. After receiving the identity certificate back from the issuing CA, you can install it.
Figure 4: Sample of a generated CSR
Although the CCNA security (650-554 IINS) book includes few chapters about certificates concepts and configuration of IPsec site-to-site tunnel using digital certificates, this topic is not really tested during the exam. But if you have planned to progress your Cisco security exam career, I recommend having a clear idea of what it has been treated on this article as these technologies take a large part of the CCNP security exam path and they are massively implemented in the real world.