Configuring and deploying Cisco IOS certificate server

5/5 - (2 votes)



A Certificate Authority is a trusted entity is that issues digital certificates to devices which need secure communication and plays an important part in the public key infrastructure (PKI). There are several CA implementations provided by third-party CA vendors like Microsoft or the open source OpenSSL implementation but in this article we will focus on configuring the internal Certificate Authority server which is available on Cisco IOS. We will also discuss about the certificate enrollment process with a CA and how these digital certificates can be used for authentication purposes. This feature has been introduced in Cisco IOS version 12.3(4)T and it’s available only on Cisco IOS images with the security feature set.

Prerequisites for configuring a Cisco IOS CA server

We will use the following topology for our configuration. The router CA-SERVER is connected to the inside network and has the IP address The ASA firewall ASA-FW will be used as a client for certificate enrollment and has the IP address set on the inside interface Gi0/1.

Cisco IOS CA server

Before starting to configure the CA server we need to ensure that the prerequisites are met. First the CA server needs to have accurate time which is needed for the successful deployment and validation of the certificates. This can be done by manually configuring the clock or by using NTP (Network Time Prococol). To manually set the clock you can use the clock set command in privileged EXEC mode.

CA-SERVER# clock set 18:13:55 21 July 2016

If you are using NTP as the time source you can specify the NTP server by using the ntp server command.

CA-SERVER(config)# ntp server

If the clock is not set or is invalid, the following message is displayed at bootup.

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

After the clock has been set, the certificate server automatically switches to running status. The Cisco IOS CA server supports the use of SCEP (Simple Certificate Enrollment Protocol) so we need to enable the HTTP server in order to use it. SCEP is used to automate certificate enrollment to clients. If the HTTP server is disabled we are limited only to manual PKCS10 enrollment. We want to use SCEP so let’s enable the HTTP server.

CA-SERVER(config)# ip http server

Configuring the Cisco IOS CA server

Now that we have fullfilled the prerequisites, first step is to generate and RSA key pair. We can simply enable the certificate server which will automatically generate an 1024-bit RSA key or we can manually generate your own key pair. Cisco recommends to use a 2048-bit modulus for the certificate server RSA key pair so let’s manually generate our own key pair using the crypto key generate rsa command.

CA-SERVER(config)# crypto key generate rsa general-keys label ROOT-CA modulus 2048 exportable
The name for the keys will be: ROOT-CA

% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be exportable...
[OK] (elapsed time was 1 seconds)

*Jul 21 07:12:24.905: %SSH-5-ENABLED: SSH 1.99 has been enabled

For the generated the key pair I used a modulus size of 2048-bit. I also specified a label named ROOT-CA and made the key exportable which is useful for backup, or archive purposes. It is recommended that the private key be kept in a secure location. When we will define the certificate server’s name we need to use the same label as the one used for the key pair. Next we need to define a trustpoint (which is in fact a trusted certificate authority) which allows us to specify the previous generated RSA key pair.

CA-SERVER(config)# crypto pki trustpoint ROOT-CA
CA-SERVER(ca-trustpoint)# rsakeypair ROOT-CA

Let’s proceed and enable the actual CA server. First we need to specify the CA server name (ROOT-CA) to be the same as the key pair label. After this we will enter in certificate server configuration mode

CA-SERVER(config)# crypto pki server ROOT-CA

All CS-related commands are optional therefore you can use the default provided values for any functionality you do not want to customize. For our scenario let’s customize some of the options to better understand what they do. It’s recommended to set all your options before starting the certificate server otherwise the following message will be displayed warning you that the CA server needs to be shutdown before any changes can be made.

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

Let’s configure the issuer name values which are in fact LDAP attribute names (X.500 standard).

CA-SERVER(cs-server)# issuer-name CN=ROOT-CA,, C=RO

For a detailed explanation of these LDAP attributes you can check this page. Next we’ll configure the location for the CA server files. By default all published files are stored to NVRAM. We want to store the files on the local flash inside the CA-server directory. This directory needs to be created if it does not exit by running mkdir flash:/CA-server command.

CA-SERVER(cs-server)# database url flash:/CA-server/

This commands supports also remote storage locations like ftp:// or tftp://. Now let’s define what type of data we want to store in the database. The default value is minimal but we’ll choose complete for our database.

CA-SERVER(cs-server)# database level complete

Now I’ll configure the hash function used to sign the certificates issued by the CA server. The default value is MD5 (not recommended anymore) but I’ll use SHA-512 which is the most secure now.

CA-SERVER(cs-server)# hash sha512

Let’s change the lifetime parameters for the root CA certificate, the certificates issued to clients and the certificate revocation lists CRLs. I’ll choose 1825 days (5 years) for the root CA certificate, 365 days (1 year) for the issued certificates and 24 hours (1 day) for the CRLs.

CA-SERVER(cs-server)# lifetime ca-certificate 1825
CA-SERVER(cs-server)# lifetime certificate 365
CA-SERVER(cs-server)# lifetime crl 24

The default granting mode for SCEP enrollment requests is manual and this requires administrator input for valdation. I have added the command below for reference.

CA-SERVER(cs-server)# no grant auto

Now we can enable the CA server by issuing the no shutdown command. This will require you to enter a passphrase twice in order to protect the private key. Remember to enter a passphrase of at least 7 characters otherwise a warning will be issued.

CA-SERVER(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

Re-enter password:
*Jul 21 20:30:22.071: %PKI-6-CS_ENABLED: Certificate server now enabled.

We can check the status of the CA server by running the following command:

CA-SERVER# show crypto pki server 
Certificate Server ROOT-CA:
    Status: enabled
    State: enabled
    Server's configuration is locked  (enter "shut" to unlock it)
    Issuer name: CN=ROOT-CA,, C=RO
    CA cert fingerprint: F1C86EB4 6408EFFF F595F5E1 EA4EF8F7 
    Granting mode is: manual
    Last certificate issued serial number (hex): 1
    CA certificate expiration timer: 23:25:18 EEST Jul 18 2021
    CRL NextUpdate timer: 23:25:20 EEST Jul 20 2016
    Current primary storage dir: flash:/CA-server
    Database Level: Complete - all issued certs written as <serialnum>.cer

Looking at this output we can observe the current values for all the options we have configured previously like issuer name, granting mode, lifetime, database location and level etc.

Client certificate enrollment

Now that the certificate server configuration is done let’s proceed with the client enrollment process. Our client in this scenario will be the ASA-FW firewall. Let’s connect to the ASA-FW console and generate an RSA key pair which will be used for enrollment.

ASA-FW(config)# crypto key generate rsa label modulus 2048

Next we need to define the trustpoint and configure how the client would enroll with the CA server.

ASA-FW(config)# crypto ca trustpoint ROOT-CA

Since we are using SCEP for enrollment we need to specify the URL of the CA server to which the client should send certificate requests. We will use the HTTP protocol and specify the IP address or the DNS name of the CA server. SCEP also supports TFTP, FTP or HTTPS protocols for enrollment. Our CA server has the IP address of If you are using an IPv6 address in the URL you need to enclose it in square brackets.

ASA-FW(config-ca-trustpoint)# enrollment url

Next let’s specify the requested subject name that will be used in the certificate request. Default is to use the fully qualified domain name (FQDN).

ASA-FW(config-ca-trustpoint)# subject-name CN=ASA-FW,O=Cioby,C=RO

Now let’s setup the key pair to associate with the certificate and the method to check the revocation status of a certificate.

ASA-FW(config-ca-trustpoint)# keypair
ASA-FW(config-ca-trustpoint)# revocation-check crl

The revocation-check command is used to ensure that the certificate of a peer has not been revoked. Before certificate enrollment can occur we need to authenticate the CA to the client ASA-FW. This will obtain the self-signed certificate of the CA that contains the public key of the CA.

ASA-FW(config)# crypto ca authenticate ROOT-CA
INFO: Certificate has the following attributes:
Fingerprint:     f1c86eb4 6408efff f595f5e1 ea4ef8f7 
Do you accept this certificate? [yes/no]: yes

Trustpoint CA certificate accepted.

When entering the crypto ca authenticate command you’ll be asked to accept the root certificate provided by the CA. It’s recommended to compare the fingerprint on the CA server with the one on the client and if they match you should accept the certificate as valid. Now we are ready to enroll the client with the CA server by using the crypto ca enroll command.

ASA-FW(config)# crypto ca enroll ROOT-CA
% 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 be: CN=ASA-FW, O=Cioby, C=RO
% The fully-qualified domain name in the certificate will be: ASA-FW
% Include the device serial number in the subject name? [yes/no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority

This will generate a certificate request on the CA server and it will ask you twice for a password which is needed for certificate revocation. After this you need to confirm whether you want to include the serial number into the subject name and finally type yes to send the request to the CA server. Since we set the granting mode on the CA server to manual by issuing the no grant auto command we need to manually validate each certificate request.

Now let’s check the pending certificate requests on the CA server using the show crypto pki server requests command.

CA-SERVER# show crypto pki server ROOT-CA 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    BA54066ECC0665F13B2A409E5A42EBC2 hostname=ASA-FW,cn=ASA-FW,o=Cioby,c=RO

From the last line of the above output we can observe that we have one pending certificate request belonging to our client ASA-FW firewall. Let’s grant the manual enrollment requests for the certificate server ROOT-CA. We can use the “all” keyword to grant all requests or we can use the request ID to grant only specific requests. Since we have only one pending request let’s use the request ID.

CA-SERVER# crypto pki server ROOT-CA grant 1

Let’s go back to the client console and check that the signed certificate is available by using the show crypto ca certificates command.

ASA-FW# show crypto ca certificates
  Status: Available
  Certificate Serial Number: 02
  Certificate Usage: General Purpose
  Public Key Type: RSA (2048 bits)
  Signature Algorithm: SHA512 with RSA Encryption
  Issuer Name: 
  Subject Name:
  Validity Date: 
    start date: 07:06:08 UTC Jul 22 2016
    end   date: 07:06:08 UTC Jul 22 2017
  Associated Trustpoints: ROOT-CA

This will display information about the certificate like the status, issuer name, validity. Now that the certificate has been issued and it’s valid it can be used for different purposes like VPN authentication.


In this article we discussed the basic steps needed to setup a CA server and how to manually enroll a client with the CA server. I hope you found this article useful and I’m looking forward to join me in the next one.

One comment

  • jaro

    Hello, it’s not mentioned here but I noticed that the trustpoint name on the CA need to be the same as the CA server name. Otherwise trustpoint will be automatically configured and that with the different name will be not used. Is that true?

Leave a Reply

Your email address will not be published.