This is the third article in this series discussing the certificate authority (CA). In the last two articles, we have seen what role the CA plays in the public key infrastructure (PKI uses the asymmetric key cryptography). We also looked at the certificate enrollment process with a CA and how these digital certificates are used for authentication purposes.
In this article, we will configure a Cisco router to serve as a certificate authority and we will use the issued certificates to authenticate two VPN peers. The network diagram we will be using is shown below. VPN-RTR1 and VPN-RTR2 will get certificates from the Cisco-IOS-CA, which will be used for authentication purposes for the VPN to secure traffic between 22.214.171.124 and 126.96.36.199.
Let’s begin with the configuration of the Cisco IOS certificate server. The basic configuration (IP addressing, etc.) has been done on all devices. Because certificates are time-based, it is important to make sure that you have the correct clock settings on all your devices. One way to do that is to use NTP for time synchronization. The certificate server is configured to act as the NTP master.
The first thing we need to do is to generate an RSA key pair. We can either manually generate our own RSA key pair or we can let the router generate it automatically when we enable the certificate server. If you decide to generate your own RSA key pair (using the crypto key generate rsa command), then the name you specify as the certificate server name must be the same as the label you specified when generating the RSA key pair. We will go with this method for the sake of completeness. Moreover, generating our own key pair allows us to specify the key size and other parameters, such as where to store the key pair and whether it should be exportable.
The Cisco IOS certificate server supports the use of simple certificate enrollment protocol (SCEP) for enrollment and other PKI operations. SCEP runs over HTTP, therefore the HTTP server must be enabled on the Cisco IOS certificate server. SCEP services are automatically enabled or disabled when the HTTP server is enabled or disabled. Without SCEP, only manual enrollment is possible, so let’s enable the HTTP server.
Now that we have generated our key pair and enabled the HTTP server for SCEP functionality, we can go ahead to configure and enable the IOS CA. Remember that the name of the certificate server must be the same as the name of our key pair. We specify the certificate server using the crypto pki server command.
Several options can be configured under the certificate server. One thing to note is that some changes cannot be made after the certificate server has been started using the no shutdown, as shown in the warning below. Therefore, it is better to set your parameters before starting the certificate server; otherwise, you will have to shut down the server, make the changes, and then restart it.
If you decide to proceed without changing any parameters, the default settings of the certificate server will be used. However, let’s makes some changes. We can change the issuer name string. There are some attributes we will use, such as CN, which stands for “common name,” and C, which stands for “Country.” These attributes are known as LDAP attribute names. Note that using “?” does not provide help on these attributes. You can, however, look at common LDAP attributes here or here.
We can also change lifetime parameters for the signing certificate of the certificate server, certificates issued by the certificate server, the CRLs, and the enrollment requests.
We will change the lifetime of the certificate server signing certificate. You specify the lifetime in days.
1825 days is 5 years. Let’s also change the lifetime of the issued certificates to 1 year.
Finally, we can allow the certificate server to automatically grant SCEP enrollment requests without requiring any administrator input.
At this point, we will enable the certificate server. It requires a passphrase to protect the private key.
We can view our certificate server settings using the show crypto pki server command.
We can also take a look at the self-signed certificate that the Cisco IOS certificate server issued to itself. You will notice that the certificate contains the different fields we mentioned in the previous article, such as version, issuer details, subject details, and so on. You can also see from the output that the certificate is valid for 5 years, as we configured.
I mentioned that this certificate is a self-signed certificate. One of the ways to recognize a self-signed certificate is that the issuer and the subject are the same.
Now that we have configured and enabled the Cisco IOS Certificate server, it is ready to start issuing certificates. Want to see how that is done? Well, find out in the next article 🙂
In this article, we have seen how to configure the Cisco router to act as a certificate authority (called a certificate server because it can act in other modes such as a registration authority). Points to keep in mind include: You should configure time synchronization; if you generate your own RSA key pair, the name of the certificate server must be the same as the label of the key pair; and you ought to set your certificate server options before enabling it. We also looked at the self-signed certificate generated by the certificate server and saw that it contained the various certificate fields we discussed in the previous article.
Great! I feel excited. I didn’t know this certificate authority series will be so much fun to work on. I hope you are enjoying it as much as I am.
I look forward to you joining me in the next article, where we will see the certificate server in action issuing certificates to our VPN routers.
Reference and helpful resource:
Configuring and Managing a Cisco IOS Certificate Server for PKI Deployment: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_pki/configuration/12-4t/sec-cfg-mng-cert-serv.html