CA Server on a Cisco Router

Most of the time when I am in the field setting up VPNs, I am using pre shared keys for authentication. pre-shared Most of my customers are not really concerned about setting up a PKI infrastructure that is required in order to use a certificate based VPN. Nevertheless, allowing routers to use certificates for authentication less, allows for an additional layer of security by making is more difficult to create man-in-the-middle attacks. man While it would be nice to create an internal CA and RA infrastructure in a lab, it really isnt necessary to understand the base concepts of getting certificates installed and used for the purpose of a VPN. In fact, we can use a Cisco router to setup a CA server that issues certificates for this very purpose! Yay! For this exercise, the layout will be used for a future lab involving the not-so EzVPN. Instead of using e not so pre-shared keys for the EzVPN, certificates are going to be used instead. But to use those certificates shared will require a CA server and enrollment to the server. Here is the current lab:

R1 is going to be the CA Server, while R2 and R3 are going to enroll in the CA server. R2 will then connect to R3 using EzVPN (which can be saved for another post). So what exactly happens with a CA server? A CA server is a Certificate Authority, which means that it m has the authority to sign certificates that are used by members of the domain (or any device that it grants a certificate). When a device installs a CA certificate, that device says that it will trust any other certificate that was signed by that server. Therefore, if there are five devices that are talking to each other, and each device has the same CA certificate installed, then they all know that certificates that were signed by the CA can be trusted. If the certificate was not signed by the CA, it is not considered trusted. The following steps will need to be taken:

1. Configure NTP on the server and clients. 2. Generate exportable keys on the CA server. 3. Generate a public/private key pair. 4. Create a database to store the certificate. 5. Configure the PKI server. 6. Start the PKI server, which generates the CA Certificate. 7. Generate non-exportable keys on each client. 8. Create a trustpoint on each client that points to the CA Server. 9. Authenticate against the CA server. 10. Enroll with the CA server. 11. Grant requests on the server for each enrollment request. NTP MUST be configured and running on all clients and the PKI server. The certificates are time based, and not getting this done first will result in some real nastiness. For the purposes of this lab, NTP has already been configured. On R1, we generate exportable keys: R1(config)#crypto key gen rsa gen label kidvelvet exportable The name for the keys will be: kidvelvet Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys, keys will be exportable...[OK] R1(config)# Feb 14 23:44:03.664: %SSH-5-ENABLED: SSH 1.99 has been enabled If you use the default 512 modulus, SSH 1.5 will be enabled (which is version 1 only). Version 1.99 is Cisco parlance for both versions 1 and 2. Yeah, I know Now the keys are exported into a PEM format int nvram using either DES or 3DES encryption. Please do not use DES. You might as well be encrypting it with a Capn Crunch decoder ring. Anyway R1(config)#crypto key export rsa kidvelvet pem url nvram: 3des cisco123 % Key name: kidvelvet Usage: General Purpose Key Exporting public key... Destination filename [kidvelvet.pub]? Writing file to nvram:kidvelvet.pub Exporting private key... Destination filename [kidvelvet.prv]? Writing file to nvram:kidvelvet.prv

Verify the keys: R1(config)#do sh crypto key mypubkey rsa % Key pair was generated at: 23:44:03 UTC Feb 14 2011 Key name: kidvelvet Storage Device: not specified Usage: General Purpose Key Key is exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00A64D6E CBE95BF2 66AAEDA2 8E12A033 08B6A4A1 CE86E1E3 7698B146 04AF26FC 697CBAA1 E28F0965 BA61FC01 21C9D743 45BF3C7A 8D11A5AE F6198027 41ED7477 104AE448 8CA5B40A CB932829 FA9319B2 B0931950 F797654F 8267C257 06A6EAB1 A5F36BED BEF073AB DB4D11C5 1F7EE5E9 9227ED4B 5C7D072C ED568559 3D02B14D 11020301 0001 % Key pair was generated at: 23:44:05 UTC Feb 14 2011 Key name: kidvelvet.server Temporary key Usage: Encryption Key Key is not exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00A1F93C FC636CC3 646FB928 15398065 4D0725B1 40D1D7DD 9AADD9F3 09A55C62 CFB710B2 F910E65F 3F193814 52412C49 A00CE841 4A303AD0 E5263B2C BFCE32BE 994ADB67 A4710C30 0E61F5BF A4418CEB 94D118E9 049A5979 762179AF 3D6B28C8 6F020301 0001 So far, so good. Turn on the HTTP server so that the clients can enroll: R1(config)#ip http server Now we are ready to create the PKI server. This is where the certificate will be generated for the CA Server. This certificate will be used at the client trustpoints to verify that the local certificates were signed by a trusted authority. R1(config)#crypto pki server kidvelvet R1(cs-server)#database url nvram: % Server database url was changed. You need to move the % existing database to the new location. R1(cs-server)#data level min R1(cs-server)#issuer-name CN=kidvelvet.kidvelvet.local L=Hillsboro C=US R1(cs-server)#lifetime ca-ser R1(cs-server)#lifetime ca-cer R1(cs-server)#lifetime ca-certificate 365 R1(cs-server)#no shut %Some server settings cannot be changed after CA certificate generation.

% Please enter a passphrase to protect the private key % or type Return to exit Password: Re-enter password: % Exporting Certificate Server signing certificate and keys... % Certificate Server enabled. R1(cs-server)# Feb 14 23:46:53.236: %PKI-6-CS_ENABLED: Certificate server now enabled. Our CA Server is ready and open for business! The clients are a bit easier to configure. First, the keys must be generated. These do not need to be exportable. R3(config)#crypto key gen rsa % Please define a domain-name first. Oh, yeahthere is this thing that must be done before generating keys. Define a host name and domain name. At least Cisco said please R3(config)#hostname R3 R3(config)#ip domain-name kidvlevet.local R3(config)#crypto key gen rsa The name for the keys will be: R3.kidvlevet.local Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys, keys will be non-exportable...[OK] R3(config)# Feb 15 00:49:51.732: %SSH-5-ENABLED: SSH 1.99 has been enabled Version 1.99 is upkeys generated The trustpoint is the next step. There are some options here, but the main option is the enrollment url: R3(config)#crypto ca trustpoint kidvelvet R3(ca-trustpoint)#enroll url http://10.10.10.1:80 R3(ca-trustpoint)#rev none R3(ca-trustpoint)#exit Next, authenticate against the CA Server defined in the trustpoint to download the CA certificate:

R3(config)#crypto ca auth kidvelvet Certificate has the following attributes: Fingerprint MD5: 393B5E2E 740B2173 411BBCC2 BE9B9955 Fingerprint SHA1: 17501051 B95BF739 39B7A116 8A12B7A3 EFC9B5E9 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. Got the cert, now it is time to enroll and receive a cert for the client: R3(config)#crypto ca enroll kidvelvet % % Start certificate enrollment .. % Create a challenge password. You will need to verbally provide this password to the CA Administrator in order to revoke your certificate. For security reasons your password will not be saved in the configuration. Please make a note of it. Password: Re-enter password: % The subject name in the certificate will include: R3.kidvlevet.local % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]: no Request certificate from CA? [yes/no]: yes % Certificate request sent to Certificate Authority % The 'show crypto ca certificate kidvelvet verbose' commandwill show the fingerprint. R3(config)# Feb 15 00:51:01.504: CRYPTO_PKI: Certificate Request Fingerprint MD5: FE071EED 0069A988 F75597AA E1C876D3 Feb 15 00:51:01.508: CRYPTO_PKI: Certificate Request Fingerprint SHA1: FAE6C472 B328BDA1 64EF24CC A615B7B5 ACF8FB6C R3(config)# Verify the certificates: R3(config)#do sh crypto ca cert Certificate Status: Available Certificate Serial Number: 0x4 Certificate Usage: General Purpose Issuer:

cn=kidvelvet.kidvelvet.local L=Hillsboro C=US Subject: Name: R3.kidvlevet.local hostname=R3.kidvlevet.local Validity Date: start date: 00:51:24 UTC Feb 15 2011 end date: 23:46:52 UTC Feb 14 2012 Associated Trustpoints: kidvelvet CA Certificate Status: Available Certificate Serial Number: 0x1 Certificate Usage: Signature Issuer: cn=kidvelvet.kidvelvet.local L=Hillsboro C=US Subject: cn=kidvelvet.kidvelvet.local L=Hillsboro C=US Validity Date: start date: 23:46:52 UTC Feb 14 2011 end date: 23:46:52 UTC Feb 14 2012 Associated Trustpoints: kidvelvet R3(config)# We have both of the certificates. However, I had to do a little magic to make it happen. With the current configuration, the certificate will be placed in a pending state, waiting for the CA Server to grant the cert. On the CA Server, the following will show a list of certificate requests: R1#crypto pki server kidvelvet info requests Enrollment Request Database: Subordinate CA certificate requests: ReqID State Fingerprint

SubjectName

-------------------------------------------------------------RA certificate requests: ReqID State Fingerprint SubjectName -------------------------------------------------------------Router certificates requests: ReqID State Fingerprint SubjectName --------------------------------------------------------------

pending

FE071EED0069A988F75597AAE1C876D3

hostname=R3.kidvlevet.local 1 granted C15C833ED28A14D331AE40146C24A1C0 hostname=R2.kidvelvet.local Here, R3 is in a pending state. R3 has sent the enrollment request, but the request needs to be granted: R1#crypto pki server kidvelvet grant 3 The request ID of 3 is granted, and the resulting output: R1#crypto pki server kidvelvet info requests Enrollment Request Database: Subordinate CA certificate requests: ReqID State Fingerprint SubjectName -------------------------------------------------------------RA certificate requests: ReqID State Fingerprint

SubjectName

-------------------------------------------------------------Router certificates requests: ReqID State Fingerprint SubjectName -------------------------------------------------------------3 granted FE071EED0069A988F75597AAE1C876D3 hostname=R3.kidvlevet.local 1 granted C15C833ED28A14D331AE40146C24A1C0 hostname=R2.kidvelvet.local Now that it is granted, the certificate shows up in the Available status rather than the Pending status. A festivus miracle! Our certs are now ready to use with any VPN technology that comes our wayincluding the dreaded EzVPN. Good luck!