Welcome to the 4th article of this series on the Certificate Authority. We started off the series by looking at an overview of Cryptography and then we branched off into public key cryptography. We then introduced the Certificate Authority and looked at the digital certificate enrollment process and how these digital certificates are used for authentication purposes.
Most recently, in the previous post, we began with configuring the Cisco IOS router to act as a Certificate Authority. We got as far as configuring the Cisco IOS Certificate Server and we will now continue with enrolling the VPN routers with this Certificate Server.
The network diagram remains the same as the one in the previous article, as shown below:
In the last article, we started with the Cisco-IOS-CA, and we configured NTP, generated an RSA key pair called “IOS-CA” and we also configured and enabled the Certificate Server. (Note: I have regenerated another RSA key pair and thus another certificate since the last article). Let’s look at parts of this digital certificate.
We can also view the status of the Certification Server.
Notice that the signature algorithm used by the certificate is MD5 with RSA Algorithm and the MD5 fingerprint is “578055AF 72AC2F5F 1931114C 2DDEECD8” which is also the CA cert fingerprint as shown above.
We can now go ahead and configure the VPN routers. I will show the steps only on one of the routers as it is the same steps that need to be followed on the other one. The first thing that we want to ensure is that the time on both devices are synchronized. To ensure this synchronization, I have configured NTP on the VPN routers as shown on VPN-RTR1 below:
As with the Certificate Server, the first thing we need to do (after NTP and setting basic parameters like hostname and domain name) is to generate our RSA key pair. In this case, we do not need to be particular about the name of the key pair.
Note: The key pair does not have to be generated at this point until right before you need to enroll with the CA. If you don’t generate an RSA key pair at all, the router will automatically generate one with default values before certificate enrollment.
Now we will configure the Cisco IOS Certificate Server as a PKI trustpoint on the VPN routers. We use the crypto pki trustpoint command to achieve this. Note that the name we use here does not have to be the same name used on the Certificate Server itself.
Let us view the options we have under this configuration mode.
We will use only a subset of these options like enrollment, subject-name and revocation-check. Using the enrollment option, we can specify the enrollment method (and if required, the URL) to be used. If you remember, the reason we enabled the HTTP server on the Certificate Server is so that we can have enrollment via SCEP. It is at this point that that SCEP enrollment becomes useful to us.
Hint: I have discovered that adding a backslash after the URL e.g. http://192.168.123.3/ will not work so omit the backslash at the end.
Keep in mind that you have other options like HTTPS, FTP, TFTP, and so on. Now, let’s configure the subject name just like we did for the Certificate Server (using issuer-name).
Since we will not be using the CRL, we can also turn off certificate revocation check. There are three options for the revocation check: using CRL, no revocation check, or using OCSP (Online Certificate Status Protocol).
Now that we have defined the trustpoint (CA), we must authenticate it before we enroll with it. Authentication is just a way of defining that we trust the CA. Before we do this, let me show you that there are currently no digital certificates.
We will now authenticate the CA using the crypto pki authenticate command.
Notice that when you try to authenticate the CA, it shows you those fingerprint values contained in the CA digital certificate. Once you confirm that the fingerprint is the same, you can go ahead and accept the certificate by typing “yes.” Now let’s check our certificates again.
Cool! This means after authentication, we now have the digital certificate of the CA and this certificate is under the “CA Certificate” heading.
At this stage we are ready to enroll with the CA for our own certificate. This is the final step which is done using the crypto pki enroll command.
You will need to provide a challenge password which you must remember in the event that you want your certificate revoked. This is done so that certificates are not revoked mistakenly or fraudulently. After we enter a password, the router will ask some questions like whether to include the router serial number and an IP address in the subject name. You have to give some thought to these questions especially with the IP address since it may change.
If you have logging enabled, when the certificate is granted, you will get a message similar to the one shown below:
I did not have to do anything on the Cisco IOS Certificate Server because when defining the Certificate Server, we specified that SCEP requests should be granted automatically (grant auto).
Now when we check the certificates we have on the router, another one should have been added.
This certificate is placed under “Certificate” so we know it is different from the CA certificate. Also notice the highlighted parts above: it shows the issuer details; it also shows the subject details which is the FQDN of the VPN router; and you can see that the certificate is valid for only one year like we configured on the Certificate Server. I have also enrolled with the CA for VPN-RTR2 and its certificate is shown below.
Let’s go ahead and test these certificates. I have set up the VPN parameters on both routers and they use certificates (“authentication rsa-sig” under the ISAKMP policy) for authentication. To test this, I will issue a ping from 220.127.116.11 to 18.104.22.168.
It failed at first while the tunnel was being initiated but after the tunnel was brought up, you can see that the ping packets went through. Let’s confirm that we used digital certificate for authentication.
And as you can see below, the ping packets went through the tunnel:
Great! So it works. Maybe in another article on VPNs, we will look into details about how digital certificates are actually used for authentication by viewing the debug output.
This brings us to the end of this article and this subsection of the series where we have configured the Cisco router to act as a Certificate Authority. In this article, we saw how to authenticate and enroll with the Cisco IOS Certificate Server and we used the digital certificates obtained for VPN authentication purposes.
In the next article, we will configure the Cisco ASA to act as a certificate authority just like we have done for the Cisco IOS.
I hope you have found this article helpful and I look forward to writing other insightful articles.
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