top of page

PKI - CA Server and Client enrollment using Cisco Routers

Date: 7-9-2016

   Table of Contents
   Introduction

A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify the identity of the other party.

Without PKI, sensitive information can still be encrypted (ensuring confidentiality) and exchanged, but there would be no assurance of the identity (authentication) of the other party. Any form of sensitive data exchanged over the Internet is reliant on PKI for security.

  • PKI is a mechanism for providing secure communication in a network. It’s scalable and secure.

  • For PKI there should be at least one Certificate Authority (CA) that :

    • Maintains.

    • Grants.

    • And revokes certificates.

  • These certificates are used to allow secure communication among peers by identifying peers, giving a certificate validity period, and encryption keys for secure communication.

  • A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify the identity of the other party.

  • PKI is the service framework needed to support large-scale public key-based technologies.

    • Very scalable solutions which is an extremely important authentication solution for VPNs.

  • PKI is a set of technical, organizational, and legal components that are needed to establish a system that enables large-scale use of public key cryptography to provide authenticity, confidentiality, integrity, and nonrepudiation services.

    • The PKI framework consists of the hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates. Digital certificates are at the heart of PKI as they affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate.

A typical PKI includes the following key elements:

  • A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities.

  • A registration authority, often called a subordinate CA, certified by a root CA to issue certificates for specific uses permitted by the root.

  • A certificate database, which stores certificate requests and issues and revokes certificates.

  • A certificate store, which resides on a local computer as a place to store issued certificates and private keys.

Don’t forget about two PKI Pre-Requisites :

  • Working Time Source:

    • Must be accurate for successful certificate validation.

    • Recommendation is to use NTP.

  • RSA Key Pair:

    • Required for certificate enrollment and validation.

    • Domain Name must be configured.

    • Ideally label it and mark as exportable.

Anchor 1
  Configuring an IOS CA Server
Anchor 2

Link: https://www.m00nie.com/2011/11/cisco-ios-certificate-server-set-up-and-client-enrolment/

Here I’m going to explain how to set up and manage a Cisco IOS certificate server for public key infrastructure (PKI) deployment. A certificate server embeds a simple certificate server, with limited certification authority (CA) functionality, into the Cisco software. Thus, the following benefits are provided to the user:

  • Easier PKI deployment by defining default behavior. The user interface is simpler because default behaviors are predefined. That is, you can leverage the scaling advantages of PKI without all of the certificate extensions that a CA provides, thereby allowing you to easily enable a basic PKI-secured network.

  • Direct integration with Cisco software.

 

Previous steps:

  • Configure the time using NTP (recommended).

  • Configure the hostname and the domain name.

 

Time services must be running on the router because the certificate server must have reliable time knowledge. If a hardware clock is unavailable, the certificate server depends on manually configured clock settings, such as Network Time Protocol (NTP). If there is not a hardware clock or the clock is invalid, the following message is displayed at bootup:

% Time has not been set. Cannot start the Certificate server.

NOTE Well configured and synchronised time on all devices is very important in a PKI environment.

1. RSA Key Pair – First step is to generate a private/public key pair on the CA router. The private key will be used to sign “user” certificates and the public key will distributed and used to verify certificates.

CA(config)#crypto key generate rsa usage-keys label CA-Key modulus 2048 exportable

NOTE This key doesn’t have to match with the client’s key. The recommended modulus for a certificate server RSA key pair is 2048 bits.

The certificate server uses a regular Cisco IOS RSA key pair as its CA key. This key pair must have the same name as the certificate server. If you do not generate the key pair before the certificate server is created on the router, a general-purpose key pair is automatically generated during the configuration of the certificate server.

The CA certificate and CA key can be backed up automatically one time after they are generated by the certificate server. As a result, it is not necessary to generate an exportable CA key for backup purposes.

 

2. PKI Trustpoint – The trustpoint configures what key pair will be used within the certificate server.

If the certificate server also has an automatically generated trustpoint of the same name, then the trustpoint stores the certificate of the certificate server. After the router detects that a trustpoint is being used to store the certificate of the certificate server, the trustpoint is locked so that it cannot be modified. To avoid this:

CA(config)#crypto pki trustpoint CA-Server

CA(ca-trustpoint)#rsakeypair CA-Key

CA(ca-trustpoint)#exit

NOTE Use the same key as before.

Certificate Revocation Checking (CRL): ASA and IOS support status verification using Certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP). CRL can be retrieved using HTTP, LDAP or SCEP. Cisco IOS software also supports AAA integration for certificate checking; however, additional authorization functionality is included.

A certificate revocation list (CRL) is a list of revoked certificates. The CRL is created and digitally signed by the CA that originally issued the certificates. The CRL contains dates for when each certificate was issued and when it expires. When the CRL expires, the router deletes it from its cache.

Revocation checking using crl (check the revocation status of a certificate):

CA(ca-trustpoint)#revocation-check crl

 

3. Certificate Server – Now we create and configure the actual certificate server. We configure it using the same name as the trustpoint from step 2. Then we configure a local location for the database (this can be remote) and set the database storage level to complete. Finally we configure the X.500 name information using the X.500 distinguished name (DN) format.

CA(config)#crypto pki server CA-Server

CA(cs-server)#database url nvram:

CA(cs-server)#database level ?

  complete  Each issued certificate is saved to the database

  minimum   Minimum certificate info is saved to the database

  names     Certificate serial-number & subject name is saved to the database

CA(cs-server)#database level complete

CA(cs-server)# issuer-name C=sp,L=juantrontown,O=juantronCo,OU=x.509 certs,CN=juantron.com VPN

 

4. Issuing Policy – We can either manually grant all certificate requests or automattically grant all requests. We will configure a password to provide some additional authentication when users try to enrol. First we configure sha-1 as the hash algorithm used to sign the certificates with (MD5 is the default). We configure the lifetime of the certificate servers signing certificate (5 years) when this expires all issued certificates are invalidated and users will have to re-enrol. Now we configure the lifetime of client issued certificates after which clients will have to re-enrol. Both lifetimes are counted in days.

CA(config)#crypto pki server CA-Server

CA(cs-server)#hash sha1

CA(cs-server)#lifetime ca-certificate 1825

CA(cs-server)#lifetime certificate 730

CA(cs-server)#no grant auto

 

5. CRL – Now we define the revocation policy used to create and maintain the Certificate Revocation List (CRL). In this example we configure the CRL to only be valid for an hour (the minimum). 

CA(config)#crypto pki server CA-Server

CA(cs-server)#lifetime crl 1

CA(cs-server)#exit

 

6. SCEP – To ease admin burden and provide scalability we “configure” the use of Simple Certificate Enrollment Protocol (SCEP). This is done by enabling the IOS HTTP server.

CA(config)#ip http server

NOTE Cisco IOS CA Server only supports enrollments done via Simple Certificate Enrollment Protocol (SCEP).

 

7. Enable Certificate server – Finally we enable the certificate server now that all the prerequisits have been configured. 

CA(config)#crypto pki server CA-Server

CA(cs-server)#no shutdown

%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:

% Password must be more than 7 characters. Try again

% or type Return to exit

Password:

Re-enter password:

%Some server settings cannot be changed after CA certificate generation.

% Exporting Certificate Server signing certificate and keys...

% Certificate Server enabled.

Now the Certificate server is configured and running.

We can validate this with the show crypto pki server command.

CA#show crypto pki server

Just to note that any further changes will require the certificate server to be shutdown.

Enroll an IOS Device with a CA Server – Preparing the router for CA support

Link: http://etutorials.org/Networking/Cisco+Certified+Security+Professional+Certification/Part+III+Virtual+Private+Networks+VPNs/Chapter+11+Cisco+IOS+IPSec+Certificate+Authority+Support/Configure+CA+Support+Tasks/

The process necessary to configure CA support on Cisco routers includes the following steps:

Manage the NVRAM memory usage (optional):                                                                                                                                        

Certificates and CRLs are stored in NVRAM on the router, and each certificate and CRL requires a moderate amount of memory. To preserve limited NVRAM, you can specify that certificates and CRLs won’t be stored locally (i.e. use instead a TFTP server), but can be retrieved from the CA as needed. While this method can save NVRAM, it could cause a slight performance reduction and puts additional traffic out on the network.

Set the router time and date:                                                                                                                                                                       

The router must have an accurate time and date to enroll with a CA server. The clock must be set accurately before generating RSA key pairs and enrolling with the CA server because the keys and certificates are time-sensitive. Use NTP as the recommended method.

  • NTP Server: ntp master stratum

  • NTP Client: ntp server IP_NTP_Server (recommended: use the IP of a loopback interface)

Configure the router host name and domain name.                                                                                                                              

router(config)#hostname host-name

router(config)#ip domain-name dom-name

 

In a system without a DNS server, defining a static host name-to-address mapping is possible. Each host name can be associated with up to eight IP addresses separated by spaces.

router(config)#ip host name address1 [address2...address8]

Generate an RSA key pair.                                                                                                                                                                              

RSA signatures support two mutually exclusive types of RSA key pairs.

  • General-purpose keys.

  • Special-usage keys.

To generate RSA key pairs for a Cisco device:

Rtr1(config)#crypto key generate rsa [usage-keys] [modulus modulus][label name]

Cisco recommends using a minimum modulus of 1,024 bits. for security reasons.

Note If the host name and the IP domain name weren’t created, the crypto key generate rsa command will fail.

To show the generated key pairs:

Rtr1#show crypto key mypubkey rsa

Declare a CA                                                                                                                                                                                                       

To specify what CA the router will use:

Rtr1(config)#crypto ca identity name

NOTE crypto ca commands are older version and will be replaced with crypto pki commands.

Recently, to declare the CA that the router should use and enter ca-trustpoint configuration mode:

Rtr1(config)#crypto pki trustpoint name

 

NOTE Beginning with Cisco IOS Release 12.2(8)T, the crypto ca trustpoint command unified the functionality of the crypto ca identity and crypto ca trusted-root commands, thereby replacing these commands. Now the command is crypto pki trustpoint. Although both of these existing commands allow you to declare the certification authority (CA) that your device should use, only the crypto ca identity command supports enrollment (the requesting of a device certificate from a CA).

Some options for the crypto pki trustpoint command are:

Rtr1(ca-trustpoint)# enrollment url url

Rtr1(ca-trustpoint)# subject-name cat

Rtr1(ca-trustpoint)# rsakeypair key-label

Authenticate the CA                                                                                                                                                                                        

The router needs to authenticate the validity of the CA by obtaining its self-signed certificate containing the CA’s public key. Because the CA’s certificate is self-signed, its public key should be manually authenticated by contacting the CA administrator.

To authenticate the certification authority, use :

Rtr1(config)#crypto ca authenticate name

Use the same name used to declare the CA with the crypto ca identity command.

Recently, to authenticate a IOS client to a CA Server:

Rtr1(config)#crypto pki authenticate name

Request your own certificate

The local router obtains its certificate from the CA Server using:

Rtr1(config)#crypto ca enroll name

Recently, to obtain the certificate from the CA Server:

Rtr1(config)#crypto pki enroll name

If certificates already exist for each key pair, the command will fail and a prompt will appear, advising the existing certificates be removed first. Removing the existing certificates is accomplished with the no certificate command.

Responding to Prompts: During the enrolling process with the CA, several prompts appear. The actual prompts can vary with the CA provider and over time.

A delay might occur between when the certificate request is sent and when the certificate is received by the router. The length of any delay depends on the CA authorization process.

Remember, CA(cs-server)#no grant auto so the certificate Server ¡s running in manually granting mode.

Go to the CA Server and run the following command:

CA#crypto pki server CA-Server 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

-------------------------------------------------------------------------------------------------------------------

1        pending     ED0B053CB850F2…

All requests will be displayed. Each request will have a request identifier (ReqID), the fingerprint of the information submitted (to be compared with the locallly calculated fingerprint), and the name of the requesting VPN router. Find the request being considered and validate its fingerprint against the client’s fingerprint.

To grant the request when in manual mode (not necessary if we use dynamic mode: grant auto):

CA#crypto pki server CA-Server grant 1

Upon granting the certificate, it will automatically be downloaded through SCEP by the PKI client and installed on the VPN router.

CA#crypto pki server CA-Server 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

------------------------------------------------------------------------------------------------------------------

1                  granted                                                           ED0B053CB850F2…

Now we can confirm that the client router has the signed certificate returned from the Certificate server:

client#show crypto pki certificates or show crypto ca certificates

Maintain CA interoperability (optional):                                                                                                                                                   

Delete your router’s RSA keys: crypto key zeroize rsa [keypair-label]

Then, use: crypto key generate rsa

Verify the CA support configuration                                                                                                                                                           

show clock

show ntp associations

show ntp status

show crypto key mypubkey rsa

show crypto pki trustpoint

show crypto pki certificates

 

NOTE: Your e-mail will not be shown in the output. You can use an invalid e-mail, if you want.

Thank you for your co-operation in helping me to improve.

bottom of page