Welcome back to this series on the Cisco Configuration Professional. Between this article and the previous one, I have spent over 6 hours troubleshooting why CCP wasn’t discovering my devices (after I formatted my laptop) only to discover it was my Antivirus settings.

In the preceding lab, we configured NTP because of its importance to digital certificates which this lab deals with.

Our network diagram has changed to include the third router:

CertServer

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

Task #1

This task requires us to first confirm that the clocks on all routers are synchronised. This is because digital certificates can be unforgiving: if you have incorrect time settings on your devices, you will probably run into errors trying to get a digital certificate; so better now than later.

We can verify clock settings either from the console or CCP. It will be easier to see the synchronisation via console as I can press Enter fairly quickly rather than wait for CCP to load in turn for each device.

Note: We could have viewed the time through CCP by navigating to Utilities > View > IOS Show Commands and typing show clock.

Do you see the problem? RTR1 and RTR3 have the same time (seconds offset because I couldn’t press Enter on all devices at the same time) but RTR2 has a different time – 1 hour ahead. The issue is due to the time zone setting. Cisco devices by default use the UTC (Coordinated Universal Time) time zone but we can use the clock timezone command to change the time displayed. I will be using West Africa Time (WAT) which is UTC +1 on all my devices. The screenshot below shows the change made for RTR1.

After making the change on all my routers, I should now have the same time displayed.

Keep in mind that this has not affected my NTP synchronization in any way and that RTR1 and RTR3 are still getting their time from RTR2.

Good thing we verified. Now, let’s move on with our tasks.

Task #2

In this task, we are to configure RTR2 as a Certificate Server. There are articles on this resource site that have dealt with the IOS Certificate Server feature. To configure this feature, I will select RTR2 as the community member and navigate to Configure > Security > Public Key Infrastructure > Certificate Authority Server > Overview.

There is a list of recommended features for me to configure but I won’t bother with those because I already have this router acting as the NTP master and I won’t be needing DNS for certificate enrolment; I will just go ahead and click on the Create Certificate Authority (CA) Server button. This brings up the CA Server wizard as shown below.

On the next screen, we can configure the name, granting method and attributes for the CA server.

We will also click on the Advanced Options button so that we can change the lifetime of certificates as required by the task.

On the next screen, RSA keys will be created. Remember that with the IOS Certificate Server, the RSA keypair label must be the same as the name of the Certificate Server.

When we are done, we get a summary screen of the configuration that will be made and we can click on the Finish button.

The configuration that will be sent to the router is as follows:

no ip access-list extended OUTSIDE_IN
ip access-list extended OUTSIDE_IN
 remark filter inbound traffic on Fa0/0
 remark CCP_ACL Category=1
 permit tcp any host 192.168.12.2 eq www
 remark permit 1.1.1.1 to access 22.22.22.22
 permit ip host 1.1.1.1 host 22.22.22.22
 permit tcp host 112.112.112.112 host 22.22.22.22 eq telnet
 remark permit NTP from RTR1
 permit udp host 10.0.0.1 host 22.22.22.22 eq ntp
 remark deny all other connections to 22.22.22.22
 deny ip any host 22.22.22.22
 remark permit all unmatched traffic
 permit ip any any
 exit
crypto pki server RTR2_CA
 issuer-name O=Intense School, OU=CCP Series, CN=RTR2, C=US
 grant auto
 lifetime ca-certificate 1825
 lifetime certificate 730
 database archive pem password cisco123
 no shutdown
 exit

Notice that CCP automatically adds an ACE to allow connections to the CA Server, i.e. permit tcp any host 192.168.12.2 eq www. After the configuration is delivered, the CA Server will then be enabled.

My Certificate Server came up “stopped” and I got the following message on my console:

Whether I type yes or no, the Certificate Server doesn’t come up. We can take a look at the server details using the show crypto pki server command.

The error has actually been revealed in the console screenshot above: The router already has a self signed certificate. When we configured the Certificate Server through CCP, the router tries to generate another self-signed certificate with the parameters we specified (e.g. CN=RTR2, OU=CCP Series) but since there is already a self-signed certificate, it asks us whether we want to use the existing certificate.

So the question is: what existing self-signed certificate does the router have? Do you know the answer? Join me in the next article as we walk through this issue.

Summary

In this article, we began with our 7th lab in the CCP series where we look at the Cisco IOS Certificate Server. We earlier configured NTP in our last lab and checked that the time on all devices are synchronised. We discovered that though the time was synchronised (all the routers’ internal clocks use UTC even if we configure a different time zone), the time zone settings on the routers were different, which affected the time that’s displayed. We changed this using the clock timezone command. We then moved on to enable the Certificate Server on RTR2 and although the wizard finished, the certificate server did not come up. Find out why in the next article.

I hope you have found this lab intriguing and helpful, and I look forward to the next article in the series.

Further reading