In the last article, we started with Lab #7 in the CCP series where we are configuring the Cisco IOS Certificate Server via CCP. We leveraged our NTP lab to make sure the clocks are synchronised on all devices. We went on to use the Certificate Server Wizard in CCP and when we finished, we discovered that our Certificate Server did not come up because the router already had a self-signed certificate.
In this lab, we will solve this issue and bring up our Certificate Server so that we can complete our tasks. Our network diagram is shown below:
The configuration tasks for Lab #7 are as follows:
* Confirm that the clocks on all routers are synchronised from the previous lab on NTP and that they are displaying the same time.
* Configure RTR2 as a certificate server with a server certificate valid for 5 years and issued certificates valid for 2 years. The CA Server should automatically grant certification requests.
* Enrol RTR1 and RTR3 with RTR2 for digital certificates.
Configuration solutions cont’d
I asked a question in the last article relating to the message we saw on RTR2 that the router already has a self-signed certificate: what certificate is the router referring to? Remember this prompt below that comes up during CCP discovery?
If I view the certificate, this is what it looks like:
The reason we are able to connect via HTTPS to the routers is because when we enable HTTPS on the routers, they automatically generate self-signed certificates as shown above. We can also view this certificate via CCP by navigating to Configure > Security > Public Key Infrastructure > Router Certificates.
This trustpoint is ‘persistent’ meaning that even when we shutdown and restart our router, it is automatically recreated.
So what options do we have to bring up our Certificate Server since we can have only one self-signed certificate on the router? Two things come to my mind: use the certificate currently there or delete the current one and let the Certificate Server create a new one. The second option is actually preferable because in using the old certificate, there are things we cannot change like the CA certificate lifetime since it is already generated.
Before we delete that trustpoint, I want us to take a snapshot of the RSA keys we currently have on the router because I have a question coming up later that will reference this snapshot. I will navigate to Configure > Security > Public Key Infrastructure > RSA Keys.
Notice that we have just two items on that list. Now we will continue with our trustpoint deletion by navigating to Configure > Security > Public Key Infrastructure > Router Certificates and clicking the Delete button. This will delete the trustpoint and all associated certificates.
Now that we have deleted that certificate, let’s go back and check our RSA keys.
We now have three items. It seems to me that what the router is doing is automatically creating an RSA keypair and a certificate to be used exclusively for HTTPS. The only thing that the CCP documentation says about the HTTPS_SS_CERT_KEYPAIR is that it will be read-only – hence the mark beside it.
Let’s move on with our configuration. Having deleted the trustpoint, we can run our Certificate Server wizard again using the same settings we had before.
Note: If you still have the Certificate Server installed, uninstall it first and then run the wizard again.
As we can see from the snapshot above, the Certificate Server is now enabled. Also, we get a different message on the router’s console:
We can also check the certificate generated by the Certificate Server and see that it is valid for 5 years (May 15, 2014 to May 14, 2019) just like we configured.
Before we continue, I have a question for you: what do you think happens to the connection between CCP and RTR2 since we have deleted the original self-signed certificate? Actually, if we were to hit the refresh button, CCP will try to rediscover RTR2 because something has changed and then you will be presented with one of those Security Certificate Alert dialog boxes again. If we view the certificate, we will see that it is now a different certificate (compare the ‘Issuer’ section with the one above).
Do you know what certificate this is? It is the one created by that HTTPS_SS_CERT_KEYPAIR.
And you know what’s weird? The certificate doesn’t show up on the router.
The only certificate we have on the router is the CA certificate. Hmm, I wonder if this is worth investigating. Anyways, let’s continue with our lab.
We are to enrol RTR1 and RTR3 with RTR2 for digital certificates. Thankfully, there is also a wizard for that on CCP. We will start with RTR1 and navigate to Configure > Security > Public Key Infrastructure > Certificate Enrollment Wizards.
The wizard provides us with two options of receiving a certificate: SCEP or Cut-and-paste/Import from PC. We will be using SCEP so I will leave the default selected and click on the Launch the selected task button.
The SCEP Wizard screen pops up and gives us information about what will be configured.
On the next screen, I will enter the CA details. The nickname can be any name of your choice – it does not have to match with what the CA is configured with; the enrolment URL is where the CA server is located and the challenge password isn’t a required field so I will leave it blank.
We can then add attributes such as the common name and organization unit on the next screen.
I have used the Other Subject Attributes button to set more attributes.
The router will also need an RSA key pair for signing and encryption. I will use the existing key pair on the router for this purpose.
At the end of our settings, we are presented with a summary screen of what we have configured.
The configuration to be sent to the router is shown below:
crypto pki trustpoint RTR2_CA rsakeypair TP-self-signed-4279256517 subject-name O=Intense School, OU=CCP Series, CN=RTR1, C=US ip-address none enrollment url http://192.168.12.2 serial-number none password fqdn RTR1.lab.local revocation-check crl auto-enroll exit
After the configuration has been delivered to the router, the wizard tries to contact the CA server.
If it can successfully contact the CA server, the CA Server certificate should be displayed, such as the one shown below:
If you are sure of (or have confirmed) the CA Server certificate fingerprint, click on Yes to continue the enrolment process. At this point, the wizard sends the certificate request to the CA server and you can then click on Finish to exit the wizard.
Because we configured our Certificate Server to automatically grant certificates, the router should have received its certificate without any input from me. To view this certificate, we will navigate to Configure > Security > Public Key Infrastructure > Router Certificates.
Notice that the certificate received is valid for 2 years like we configured. I have done the same thing for RTR3 and we can also view the certificate it received like we did for RTR1.
Wow, this was a long article but I hope it was worth it. In this final part of Lab #7, we have enabled the Certificate Server on RTR2 and also enrolled RTR1 and RTR3 for digital certificates with our Certificate Server.
We are gradually coming to the end of the CCP series and we will round up with VPN labs. I hope you have found this article helpful and I look forward to the next article in the series.
Configuring and Managing a Cisco IOS Certificate Server for PKI Deployment: http://www.cisco.com/c/en/us/td/docs/ios/sec_secure_connectivity/configuration/guide/15_0/sec_secure_connectivity_15_0_book/sec_cfg_mng_cert_serv.html
CERTIFICATE AUTHORITY (CA): Cisco IOS Certificate Server #1: http://resources.intenseschool.com/certificate-authority-ca-cisco-ios-certificate-server-1/
Cisco Configuration Professional User Guide – Version 2.7: http://www.cisco.com/c/dam/en/us/td/docs/net_mgmt/cisco_configuration_professional/v2_7/olh/ccp.pdf