This module describes 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 IOS 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 IOS software.

Note

Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the
Next Generation Encryption (NGE) white paper.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see
Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for Configuring a Cisco IOS Certificate Server

Planning Your PKI Before Configuring the Certificate Server

Before configuring a Cisco IOS certificate server, it is important that you have planned for and chosen appropriate values for the settings you intend to use within your PKI (such as certificate lifetimes and certificate revocation list (CRL) lifetimes). After the settings have been configured in the certificate server and certificates have been granted, settings cannot be changed without having to reconfigure the certificate server and reenrolling the peers. For information on certificate server default settings and recommended settings, see the section "Certificate Server Default Values and Recommended Values."

Enabling an HTTP Server

The certificate server supports Simple Certificate Enrollment Protocol (SCEP) over HTTP. The HTTP server must be enabled on the router for the certificate server to use SCEP. (To enable the HTTP server, use the iphttpserver command.) The certificate server automatically enables or disables SCEP services after the HTTP server is enabled or disabled. If the HTTP server is not enabled, only manual PKCS10 enrollment is supported.

Note

To take advantage of automatic CA certificate and key pair rollover functionality for all types of certificate servers, Cisco IOS Release 12.4(4)T or a later release must be used and SCEP must be used as the enrollment method.

Configuring Reliable Time Services

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.

After the clock has been set, the certificate server automatically switches to running status.

For information on manually configuring clock settings, see the section "Setting Time and Calendar Services" in the chapter "Performing Basic System Management" of the Cisco IOS Network Management Configuration Guide
.

"crypto ca" to "crypto pki" CLI Change

As of Cisco IOS Release 12.3(7)T, all commands that begin as "crypto ca" have been changed to begin as "crypto pki." Although the router continues to accept crypto ca commands, all output is read back as crypto pki.

Restrictions for Configuring a Cisco IOS Certificate Server

The certificate server does not provide a mechanism for modifying the certificate request that is received from the client; that is, the certificate that is issued from the certificate server matches the requested certificate without modifications. If a specific certificate policy, such as name constraints, must be issued, the policy must be reflected in the certificate request.

RSA Key Pair and Certificate of the Certificate Server

The certificate server automatically generates a 1024-bit Rivest, Shamir, and Adelman (RSA) key pair. You must manually generate an RSA key pair if you prefer a different key pair modulus. For information on completing this task, see the section "Generating a Certificate Server RSA Key Pair."

Note

The recommended modulus for a certificate server 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.

As of Cisco IOS Release 12.3(11)T and later releases, 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.

What to Do with Automatically Generated Key Pairs in Cisco IOS Software Prior to Release 12.3(11)T

If the key pair is automatically generated, it is not marked as exportable. Thus, you must manually generate the key pair as exportable if you want to back up the CA key. For information on how to complete this task, see the section "Generating a Certificate Server RSA Key Pair."

How the CA Certificate and CA Key Are Automatically Archived

At initial certificate server setup, you can enable the CA certificate and the CA key to be automatically archived so that they may be restored later if either the original copy or the original configuration is lost.

When the certificate server is turned on the first time, the CA certificate and CA key is generated. If automatic archive is also enabled, the CA certificate and the CA key is exported (archived) to the server database. The archive can be in PKCS12 or privacy-enhanced mail (PEM) format.

Note

This CA key backup file is extremely important and should be moved immediately to another secured place.

This archiving action occurs only one time. Only the CA key that is (1) manually generated and marked exportable or (2) automatically generated by the certificate server is archived (this key is marked nonexportable).

Autoarchiving does not occur if you generate the CA key manually and mark it "nonexportable."

In addition to the CA certificate and CA key archive file, you should also regularly back up the serial number file (.ser) and the CRL file (.crl). The serial file and the CRL file are both critical for CA operation if you need to restore your certificate server.

It is not possible to manually back up a server that uses nonexportable RSA keys or manually generated, nonexportable RSA keys. Although automatically generated RSA keys are marked as nonexportable, they are automatically archived once.

Certificate Server Database

The Cisco IOS certificate server stores files for its own use and may publish files for other processes to use. Critical files generated by the certificate server that are needed for its ongoing operation are stored to only one location per file type for its exclusive use. The certificate server reads from and writes to these files. The critical certificate server files are the serial number file (.ser) and the CRL storage location file (.crl). Files that the certificate server writes to, but does not read from again, may be published and available for use by other processes. An example of a file that may be published is the issued certificates file (.crt).

Performance of your certificate server may be affected by the following factors, which should be considered when you choose storage options and publication options for your certificate server files.

The storage or publish locations you choose may affect your certificate server performance. Reading from a network location takes more time than reading directly from a router's local storage device.

The number of files you choose to store or publish to a specific location may affect your certificate server performance. The local Cisco IOS file system may not always be suitable for a large number of files.

The file types you choose to store or publish may affect your certificate server performance. Certain files, such as the .crl files, can become very large.

Note

It is recommended that you store .ser and .crl files to your local Cisco IOS file system and publish your .crt files to a remote file system.

Certificate Server Database File Storage

The certificate server allows the flexibility to store different critical file types to different storage locations depending on the database level set (see the
databaselevel command for more information). When choosing storage locations, consider the file security needed and server performance. For instance, serial number files and archive files (.p12 or .pem) might have greater security restrictions than the issued certificates file storage location (.crt) or the name file storage location (.cnm).

The table below shows the critical certificate server file types by file extension that may be stored to a specific location.

Cisco IOS certificate server files may be stored to three levels of specificity:

Default location, NVRAM

Specified primary storage location for all critical files

Specified storage location for specific critical file(s).

A more specific storage location setting overrides a more general storage location setting. For instance, if you have not specified any certificate server file storage locations, all certificate server files are stored to NVRAM. If you specify a storage location for the name file, only the name file is stored there; all other files continue to be stored to NVRAM. If you then specify a primary location, all files except the name file is now stored to this location, instead of NVRAM.

Note

You may specify either .p12 or .pem; you cannot specify both types of archive files.

Certificate Server Database File Publication

A publish file is a copy of the original file and is available for other processes to use or for your use. If the certificate server fails to publish a file, it does cause the server to shut down. You may specify one publish location for the issued certificates file and name file and multiple publish locations for the CRL file. See the table below for files types available for publication. You may publish files regardless of the database level that is set.

Table 2

Certificate Server Publish File Types

File Extension

File Type

.crl

The CRL publish location.

.crt

The issued certificates publish location.

.cnm

The certificate name and expiration file publish location.

Trustpoint of 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.

Before configuring the certificate server you can perform the following:

Manually create and set up this trustpoint (using the cryptopkitrustpointcommand), which allows you to specify an alternative RSA key pair (using thersakeypair command).

Specify that the initial autoenrollment key pair is generated on a specific device, such as a configured and available USB token, using the on command.

Note

The automatically generated trustpoint and the certificate server certificate are not available for the certificate server device identity. Thus, any command-line interface (CLI) (such as theiphttpsecure-trustpoint command) that is used to specify the CA trustpoint to obtain certificates and authenticate the connecting client's certificate must point to an additional trustpoint configured on the certificate server device.

If the server is a root certificate server, it uses the RSA key pairs and several other attributes to generate a self-signed certificate. The associated CA certificate has the following key usage extensions--Digital Signature, Certificate Sign, and CRL Sign.

After the CA certificate is generated, attributes can be changed only if the certificate server is destroyed.

Note

A certificate server trustpoint must not be automatically enrolled using the auto-enroll command. Initial enrollment of the certificate server must be initiated manually and ongoing automatic rollover functionality may be configured with the auto-rollover command. For more information on automatic rollover functionality, see the section "Automatic CA Certificate and Key Rollover."

Certificate Revocation Lists (CRLs)

By default, CRLs are issued once every 168 hours (1 calendar week). To specify a value other than the default value for issuing the CRL, execute the lifetimecrl command. After the CRL is issued, it is written to the specified database location as ca-label.crl, where ca-label is the name of the certificate server.

CRLs can be distributed through SCEP, which is the default method, or a CRL distribution point (CDP), if configured and available. If you set up a CDP, use the cdp-urlcommand to specify the CDP location. If the cdp-url command is not specified, the CDP certificate extension is not included in the certificates that are issued by the certificate server. If the CDP location is not specified, Cisco IOS PKI clients automatically request a CRL from the certificate server with a SCEP GetCRL message. The CA then returns the CRL in a SCEP CertRep message to the client. Because all SCEP messages are enveloped and signed PKCS#7 data, the SCEP retrieval of the CRL from the certificate server is costly and not highly scalable. In very large networks, an HTTP CDP provides better scalability and is recommended if you have many peer devices that check CRLs. You may specify the CDP location by a simple HTTP URL string for example,

cdp-url http://my-cdp.company.com/filename.crl

The certificate server supports only one CDP; thus, all certificates that are issued include the same CDP.

If you have PKI clients that are not running Cisco IOS software and that do not support a SCEP GetCRL request and wish to use a CDP you may set up an external server to distribute CRLs and configure the CDP to point to that server. Or, you can specify a non-SCEP request for the retrieval of the CRL from the certificate server by specifying the cdp-url command with the URL in the following format where cs-addr is the location of the certificate server:

It is the responsibility of the network administrator to ensure that the CRL is available from the location that is specified through the cdp-url command.

In order to force the parser to retain the embedded question mark within the specified location, enter Ctrl-v prior to the question mark. If this action is not taken, CRL retrieval through HTTP returns an error message.

The CDP location may be changed after the certificate server is running through the cdp-url command. New certificates contain the updated CDP location, but existing certificates are not reissued with the newly specified CDP location. When a new CRL is issued, the certificate server uses its current cached CRL to generate a new CRL. (When the certificate server is rebooted, it reloads the current CRL from the database.) A new CRL cannot be issued unless the current CRL has expired. After the current CRL expires, a new CRL is issued only after a certificate is revoked from the CLI.

Certificate Server Error Conditions

At startup, the certificate server checks the current configuration before issuing any certificates. It reports the last known error conditions through theshowcryptopkiservercommand output. Example errors can include any of the following conditions:

Storage inaccessible

Waiting for HTTP server

Waiting for time setting

If the certificate server experiences a critical failure at any time, such as failing to publish a CRL, the certificate server automatically enters a disabled state. This state allows the network administrator to fix the condition; thereafter, the certificate server returns to the previous normal state.

Certificate Enrollment Using a Certificate Server

A certificate enrollment request functions as follows:

The certificate server receives the enrollment request from an end user, and the following actions occur:

A request entry is created in the enrollment request database with the initial state. (See the table below for a complete list of certificate enrollment request states.)

The certificate server refers to the CLI configuration (or the default behavior any time a parameter is not specified) to determine the authorization of the request. Thereafter, the state of the enrollment request is updated in the enrollment request database.

At each SCEP query for a response, the certificate server examines the current request and performs one of the following actions:

Responds to the end user with a "pending" or "denied" state.

Generates and signs the appropriate certificate and stores the certificate in the enrollment request database.

If the connection of the client has closed, the certificate server waits for the client to request another certificate.

All enrollment requests transition through the certificate enrollment states that are defined in the table below. To see current enrollment requests, use the
cryptopkiserverrequestpkcs10 command.

Table 3

Certificate Enrollment Request State Descriptions

Certificate Enrollment State

Description

authorized

The certificate server has authorized the request.

denied

The certificate server has denied the request for policy reasons.

granted

The CA core has generated the appropriate certificate for the certificate request.

initial

The request has been created by the SCEP server.

malformed

The certificate server has determined that the request is invalid for cryptographic reasons.

pending

The enrollment request must be manually accepted by the network administrator.

SCEP Enrollment

All SCEP requests are treated as new certificate enrollment requests, even if the request specifies a duplicate subject name or public key pair as a previous certificate request.

Types of CA Servers Subordinate and Registration Authorities (RAs)

CA servers have the flexibility to be configured as a subordinate certificate server or an RA-mode certificate server.

Why Configure a Subordinate CA?

A subordinate certificate server provides all the same features as a root certificate server. The root RSA key pairs are extremely important in a PKI hierarchy, and it is often advantageous to keep them offline or archived. To support this requirement, PKI hierarchies allow for subordinate CAs that have been signed by the root authority. In this way, the root authority can be kept offline (except to issue occasional CRL updates), and the subordinate CA can be used during normal operation.

Why Configure an RA-Mode Certificate Server?

A Cisco IOS certificate server can be configured to run in RA mode. An RA offloads authentication and authorization responsibilities from a CA. When the RA receives a SCEP or manual enrollment request, the administrator can either reject or grant it on the basis of local policy. If the request is granted, it is forwarded to the issuing CA, and the CA automatically generates the certificate and return it to the RA. The client can later retrieve the granted certificate from the RA.

An RA is the authority charged with recording or verifying some or all of the data required for the CA to issue certificates. In many cases the CA undertakes all of the RA functions itself, but where a CA operates over a wide geographical area or when there is security concern over exposing the CA to direct network access, it may be administratively advisable to delegate some of the tasks to an RA and leave the CA to concentrate on its primary tasks of signing certificates and CRLs.

Automatic CA Certificate and Key Rollover

CAs--root CAs, subordinate CAs, and RA-mode CAs--like their clients, have certificates and key pairs with expiration dates that need to be reissued when the current certificate and key pair are about to expire. When a root CA's certificate and key pair are expiring it must generate a self-signed rollover certificate and key pair. If a subordinate CA or an RA-mode CA's certificate and key pair are expiring, it requests a rollover certificate and key pair from its superior CA, obtaining the superior CA's new self-signed rollover certificates at the same time. The CA must distribute the new CA rollover certificate and keys too all its peers. This process, called rollover, allows for continuous operation of the network while the CAs and their clients are switching from an expiring CA certificate and key pair to a new CA certificate and key pair.

Rollover relies on the PKI infrastructure requirements of trust relationships and synchronized clocks. The PKI trust relationships allow (1) the new CA certificate to be authenticated, and (2) the rollover to be accomplished automatically without the loss of security. Synchronized clocks allow the rollover to be coordinated throughout your network.

Automatic CA Certificate Rollover How It Works

The CA server must have rollover configured. All levels of CAs must be automatically enrolled and have
auto-rollover enabled. CA clients support rollover automatically when automatically enrolled. For more information about clients and automatic rollover, see the section " Automatic Certificate Enrollment " in the chapter "Configuring Certificate Enrollment for a PKI".

After CAs have rollover enabled and their clients are automatically enrolled, there are three stages to the automatic CA certificate rollover process.

Stage One: Active CA Certificate and Key Pair Only

In stage two, the rollover CA certificate and key pair are generated and distributed. The superior CA generates a rollover certificate and key pair. After the CA successfully saves its active configuration, the CA is ready to respond to client requests for the rollover certificate and key pair. When the superior CA receives a request for the new CA certificate and key pair from a client, the CA responds by sending the new rollover CA certificate and key pair to the requesting client. The clients store the rollover CA certificate and key pair.

Note

When a CA generates its rollover certificate and key pair, it must be able to save its active configuration. If the current configuration has been altered, saving of the rollover certificate and key pair does not happen automatically. In this case, the administrator must save the configuration manually or rollover information is lost.

In stage three, the rollover CA certificate and key pair become the active CA certificate and key pair. All devices that have stored a valid rollover CA certificate rename the rollover certificate to the active certificate and the once-active certificate and key pair are deleted.

After the CA certificate rollover, you may observe the following deviation from usual certificate lifetime and renewal time:

The lifetime of the certificates issued during rollover is lower than the preconfigured value.

In specific conditions, the renew time may be inferior to the configured percentage of the actual lifetime. The difference observed can be of up to 20% in cases where the certificate lifetime is less than one hour.

These differences are normal, and result from
jitter (random time fluctuation) introduced by the algorithm on the Certificate server. This task is performed to avoid the hosts participating to the PKI synchronize their enrollment timer, which could result in congestion on the Certificate Server.

Note

The lifetime fluctuations that occur do not affect proper functionning of the PKI, since the differences always result in a shorter lifetime, thus remaining within maximum configured lifetime for certificates.

Support for Specifying a Cryptographic Hash Function

Secure Hash Algorithm (SHA) support allows a user to specify a cryptographic hash function for Cisco IOS certificate servers and clients. The cryptographic hash functions that can be specified are Message Digest algorithm 5 (MD5), SHA-1, SHA-256, SHA-384, or SHA-512.

Note

Cisco no longer recommends using MD5; instead, you should use SHA-256. For more information about the latest Cisco cryptographic recommendations, see the
Next Generation Encryption (NGE) white paper.

See the "Configuring a Subordinate Certificate Server" task for more information on specifying the
hash (ca-trustpoint) and
hash (cs-server) commands that are used to implement this feature.

Generating a Certificate Server RSA Key Pair

Perform this task to manually generate an RSA key pair for the certificate server. Manually generating a certificate server RSA key pair allows you to specify the type of key pair you want to generate, to create an exportable key pair for backup purposes, to specify the key pair storage location, or to specify the key generation location.

If you are running Cisco IOS Release 12.3(8)T or earlier releases, you may want to create an exportable certificate server key pair for backup, or archive purposes. If this task is not performed, the certificate server automatically generates a key pair, which is not marked as exportable. Automatic CA certificate archiving was introduced in Cisco IOS Release 12.3(11)T.

As of Cisco IOS Release 12.4(11)T and later releases, if your router has a USB token configured and available, the USB token can be used as cryptographic device in addition to a storage device. Using a USB token as a cryptographic device allows RSA operations such as key generation, signing, and authentication of credentials to be performed on a USB token. The private key never leaves the USB token and is not exportable. The public key is exportable. For titles of specific documents about configuring a USB token and making it available to use as a cryptographic device, see the "Related Documents" section.

Note

It is recommended that the private key be kept in a secure location and that you regularly archive the certificate server database.

Note

Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the
Next Generation Encryption (NGE) white paper.

When specifying a label name by specifying the
key-label argument, you must use the same name for the label that you plan to use for the certificate server (through the
cryptopkiservercs-labelcommand). If a
key-label argument is not specified, the default value, which is the fully qualified domain name (FQDN) of the router, is used.

If the exportable RSA key pair is manually generated after the CA certificate has been generated, and before issuing the
noshutdown command, then use the
cryptocaexportpkcs12 command to export a PKCS12 file that contains the certificate server certificate and the private key.

By default, the modulus size of a CA key is 1024 bits. The recommended modulus for a CA key is 2048 bits. The range for a modulus size of a CA key is from 350 to 4096 bits.

The
on keyword specifies that the RSA key pair is created on the specified device, including a Universal Serial Bus (USB) token, local disk, or NVRAM. The name of the device is followed by a colon (:).

To create the imported keys on a USB token, use the
on keyword and specify the appropriate device location.

If you exported the RSA keys using the
exportable keyword and you want to change the RSA key pair to nonexportable , import the key back to the certificate server without the
exportable keyword. The key cannot be exported again.

Step 6

exit

Example:

Router (config)# exit

Exits global configuration.

Step 7

showcryptokeymypubkeyrsa

Example:

Router# show crypto key mypubkey rsa

Displays the RSA public keys of your router.

Example

The following example generates a general usage 1024-bit RSA key pair on a USB token with the label "ms2" with crypto engine debugging messages shown:

Prerequisites for Automatic CA Certificate Rollover

When configuring a certificate server, for automatic CA certificate rollover to run successfully, the following prerequisites are applicable for your CA servers:

You must be running Cisco IOS Release 12.4(2)T or a later release on your CA servers.

Your CA server must be enabled and fully configured with a reliable time of day, an available key pair, a self-signed, valid CA certificate associated with the key pair, a CRL, an accessible storage device, and an active HTTP/SCEP server.

CA clients must have successfully completed automatic enrollment and have autoenrollment enabled with the same certificate server.

Restrictions for Automatic CA Certificate Rollover

When configuring a certificate server, in order for automatic CA certificate rollover to run successfully, the following restrictions are applicable:

SCEP must be used to support rollover. Any device that enrolls with the PKI using an alternative to SCEP as the certificate management protocol or mechanism (such as enrollment profiles, manual enrollment, or TFTP enrollment) is not be able to take advantage of the rollover functionality provided by SCEP.

If you have automatic archive configured on your network and the archive fails, rollover does not occur because the certificate server does not enter the rollover state, and the rollover certificate and key pair is not automatically saved.

Defines a label for the certificate server and enters certificate server configuration mode.

Note

If you manually generated an RSA key pair, the
cs-label argument must match the name of the key pair.

Step 5

noshutdown

Example:

Router(cs-server)# no shutdown

(Optional) Enables the certificate server.

Note

Only use this command at this point if you want to use the preconfigured default functionality. That is, do not issue this command just yet if you plan to change any of the default settings as shown in the task "Configuring Certificate Server Functionality."

The following example shows how to enable automated CA certificate rollover on the server mycs with the
auto-rollover command. The
showcryptopkiservercommand shows that the automatic rollover has been configured on the server mycs with an overlap period of 25 days.

Configuring a Subordinate Certificate Server

Perform this task to configure a subordinate certificate server to grant all or certain SCEP or manual certificate requests and to enable automatic rollover.

Note

You must be running Cisco IOS Release 12.3(14)T or a later release. (Versions prior to Cisco IOS software Release 12.3(14)T support only one certificate server and no hierarchy; that is, subordinate certificate servers are not supported.)

The root certificate server should be a Cisco IOS certificate server.

Note

Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the
Next Generation Encryption (NGE) white paper.

(Optional) The
mode keyword specifies the registration authority (RA) mode, if your CA system provides an RA. By default, RA mode is disabled.

(Optional) The
retry period keyword and
minutes argument specifies the period, in minutes, in which the router waits before sending the CA another certificate request. Valid values are from 1 to 60. The default is 1.

(Optional) The
retry count keyword and
number argument specifies the number of times a router will resend a certificate request when it does not receive a response from the previous request. Valid values are from 1 to 100. The default is 10.

The
url argument is the URL of the CA to which your router should send certificate requests.

Note

With the introduction of Cisco IOS Release 15.2(1)T, an IPv6 address can be added to the
http: enrolment method. For example: http://[ipv6-address]:80. The IPv6 address must be enclosed in brackets in the URL. See the
enrollment url (ca-trustpoint) command page for more information on the other enrollment methods that can be used.

(Optional) Specifies the hash function for the signature that the Cisco IOS client uses to sign its self-signed certificates. The Cisco IOS client uses the MD5 cryptographic hash function for self-signed certificates by default.

Any of the following command algorithm keyword options can be specified to over-ride the default setting for the trustpoint. This setting then becomes the default cryptographic hash algorithm function for self-signed certificates by default.

Examples

If the certificate server fails to enable or if the certificate server has trouble handling the request that has been configured, you can use the debugcryptopkiserver command to troubleshoot your configuration as shown in the following examples (Clock Not Set and Trustpoint Not Configured):

If the certificate server fails to obtain its signing certificate from the root certificate server, you can use the debugcryptopkitransactionscommand to troubleshoot your configuration as shown in the following example:

If the certificate server fails to enable or if the certificate server has trouble handling the request that has been configured, you can use the debugcryptopkiserver command to troubleshoot the progress of an enrollment. This command can also be used to debug the root CA (turn it on at the root CA).

Configuring a Certificate Server to Run in RA Mode

The Cisco IOS certificate server can act as an RA for a Cisco IOS CA or another third party CA. Read the details in Step 8 for more information about the transparent keyword option if a third-party CA is used.

SUMMARY STEPS

1.enable

2.configureterminal

3.cryptopkitrustpoint name

4.enrollmenturlurl

5.subject-namex.500-name

6.exit

7.cryptopkiservercs-label

8.modera [transparent]

9.auto-rollover [time-period]

10.grantautorollover {ca-cert | ra-cert}

11.noshutdown

12.noshutdown

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configureterminal

Example:

Router#
configure terminal

Enters global configuration mode.

Step 3

cryptopkitrustpoint name

Example:

Router (config)# crypto pki trustpoint ra-server

Declares the trustpoint that your RA mode certificate server should use and enters ca-trustpoint configuration mode.

The certificate server must have the same name as the trustpoint that was created in Step 3 above.

Step 8

modera [transparent]

Example:

Router(cs-server)# mode ra

Places the PKI server into RA certificate server mode.

Use the transparent keyword to allow the CA server in RA mode to interoperate with more than one type of CA server. When the transparent keyword is used, the original PKCS#10 enrollment message is not re-signed and is forwarded unchanged. This enrollment message makes the IOS RA certificate server work with CA servers like the Microsoft CA server.

ca-cert--Specifies that the subordinate CA rollover certificate is automatically granted.

ra-cert--Specifies that the RA-mode CA rollover certificate is automatically granted.

If this is the first time that a subordinate certificate server is enabled and enrolled, the certificate request must be manually granted.

Step 11

noshutdown

Example:

Router(cs-server)# no shutdown

Enables the certificate server.

Note

After this command is issued, the RA automatically enrolls with the root certificate server.
After the RA certificate has been successfully received, you must issue thenoshutdown command again, which reenables the certificate server.

Perform the following steps on the router that is running the issuing certificate server; that is, configure the root certificate server that is delegating enrollment tasks to the RA mode certificate server.

Note

Granting enrollment requests for an RA is essentially the same process as granting enrollment requests for client devices--except that enrollment requests for an RA are displayed in the section "RA certificate requests" of the command output for the cryptopkiserverinfo-requests command.

SUMMARY STEPS

1.enable

2.cryptopkiservercs-label inforequests

3.cryptopkiservercs-labelgrantreq-id

4.configureterminal

5.cryptopkiservercs-label

6.grantra-auto

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router
> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

cryptopkiservercs-label inforequests

Example:

Router# crypto pki server root-server info requests

Displays the outstanding RA certificate request.

Note

This command is issued on the router that is running the issuing certificate server.

Step 3

cryptopkiservercs-labelgrantreq-id

Example:

Router# crypto pki server root-server grant 9

Grants the pending RA certificate request.

Note

Because the issuing certificate server delegates the enrollment request verification task to the RA, you must pay extra attention to the RA certificate request before granting it.

(Optional) Specifies that all enrollment requests from an RA are to be granted automatically.

Note

For the grantra-auto command to work, you have to include "cn=ioscs RA" or "ou=ioscs RA" in the subject name of the RA certificate. (See Step 2 above.)

What to Do Next

After you have configured a certificate server, you can use the preconfigured default values or specify values through the CLI for the functionality of the certificate server. If you choose to specify values other than the defaults, see the following section, "Configuring Certificate Server Functionality."

Configuring Certificate Server Functionality

After you have enabled a certificate server and are in certificate server configuration mode, use any of the steps in this task to configure basic certificate server functionality values other than the default values.

Certificate Server Default Values and Recommended Values

The default values for a certificate server are intended to address a relatively small network (of about ten devices). For example, the database settings are minimal (through the databaselevelminimalcommand) and the certificate server handles all CRL requests through SCEP. For larger networks, it is recommended that you use either the database setting "names" or "complete" (as described in thedatabaselevel command) for possible audit and revocation purposes. Depending on the CRL checking policy, you should also use an external CDP in a larger network.

Certificate Server File Storage and Publication Locations

You have the flexibility to store file types to different storage and publication locations.

SUMMARY STEPS

1.databaseurlroot-url

2.databaseurl{cnm |
crl |
crt |
p12 |
pem |
ser}
root-url

3.databaseurl {cnm |
crl |
crt}
publishroot-url

4.databaselevel {minimal |
names |
complete}

5.databaseusernameusername [password [encr-type]
password]

6.databasearchive {pkcs12 |
pem}[passwordencr-type]
password ]

7.issuer-nameDN-string

8.lifetime {ca-certificate |
certificate}
time

9.lifetimecrltime

10.lifetimeenrollment-requesttime

11.cdp-urlurl

12.noshutdown

DETAILED STEPS

Command or Action

Purpose

Step 1

databaseurlroot-url

Example:

Router (cs-server)#
database url tftp://cert-svr-db.company.com

Specifies the primary location where database entries for the certificate server are written.

If this command is not specified, all database entries are written to NVRAM.

If this command is not specified, all publish files are stored to the primary location if specified. If the primary location is not specified, all publish files are stored to NVRAM.

Step 4

databaselevel {minimal |
names |
complete}

Example:

Router (cs-server)# database level complete

Controls what type of data is stored in the certificate enrollment database.

minimal--Enough information is stored only to continue issuing new certificates without conflict; the default value.

names--In addition to the information given in the minimal level, the serial number and subject name of each certificate.

complete--In addition to the information given in the minimal and names levels, each issued certificate is written to the database.

Note

The
complete keyword produces a large amount of information; if it is issued, you should also specify an external TFTP server in which to store the data through the
databaseurl command.

Step 5

databaseusernameusername [password [encr-type]
password]

Example:

Router (cs-server)# database username user password PASSWORD

(Optional) Sets a username and password when a user is required to access a primary certificate enrollment database storage location.

Step 6

databasearchive {pkcs12 |
pem}[passwordencr-type]
password ]

Example:

Router (cs-server)# database archive pem

(Optional) Sets the CA key and CA certificate archive format and password to encrypt the file.

The default value is
pkcs12, so if this subcommand is not configured, autoarchiving continues, and the PKCS12 format is used.

The password is optional. If it is not configured, you are prompted for the password when the server is turned on for the first time.

Note

It is recommended that you remove the password from the configuration after the archive is finished.

Step 7

issuer-nameDN-string

Example:

Router (cs-server)# issuer-name my-server

(Optional) Sets the CA issuer name to the specified distinguished name (DN-string). The default value is as follows:
issuer-namecn={cs-label }.

Step 8

lifetime {ca-certificate |
certificate}
time

Example:

Router (cs-server)# lifetime certificate 888

(Optional) Specifies the lifetime, in days, of a CA certificate or a certificate.

Valid values range from 1 day to 1825 days. The default CA certificate lifetime is 3 years; the default certificate lifetime is 1 year. The maximum certificate lifetime is 1 month less than the lifetime of the CA certificate.

Step 9

lifetimecrltime

Example:

Router (cs-server)# lifetime crl 333

(Optional) Defines the lifetime, in hours, of the CRL that is used by the certificate server.

(Optional) Specifies how long an enrollment request should stay in the enrollment database before being removed.

Maximum lifetime is 1000 hours.

Step 11

cdp-urlurl

Example:

Router (cs-server)# cdp-url http://my-cdp.company.com

(Optional) Defines the CDP location to be used in the certificates that are issued by the certificate server.

The URL must be an HTTP URL.

If you have PKI clients that are not running Cisco IOS software and that do not support a SCEP GetCRL request, use the following URL format:

http://server.company.com/certEnroll/filename.crl

Or, if your Cisco IOS certificate server is also configured as your CDP, use the following URL format

http://cs-addr/cgi-bin/pkiclient.exe?operation=GetCRL

where
cs-addr is the location of the certificate server.

In order to force the parser to retain the embedded question mark within the specified location, enter Ctrl-v prior to the question mark. If this action is not taken, CRL retrieval through HTTP returns an error message.

Note

Although this command is optional, it is strongly recommended for any deployment scenario.

Step 12

noshutdown

Example:

Router (cs-server)# no shutdown

Enables the certificate server.

You should issue this command only after you have completely configured your certificate server.

Examples

The following example shows how to configure a CDP location where the PKI clients do not support SCEP GetCRL requests:

Use any of the optional steps within this task to help manage the enrollment request database by performing functions such as specifying enrollment processing parameters that are to be used by SCEP and by controlling the run-time behavior or the certificate server.

SUMMARY STEPS

1.enable

2.cryptopkiservercs-labelgrantallreq-id

3.cryptopkiservercs-labelreject
{allreq-id

4.cryptopkiservercs-labelpasswordgenerateminutes

5.cryptopkiservercs-labelrevokecertificate-serial-number

6.cryptopkiservercs-labelrequestpkcs10
{url
|
terminal} [base64| pem

7.cryptopkiservercs-labelinfocrl

8.cryptopkiservercs-labelinforequests

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

cryptopkiservercs-labelgrantallreq-id

Example:

Router# crypto pki server mycs grant all

Grants all or specific SCEP requests.

Step 3

cryptopkiservercs-labelreject
{allreq-id

Example:

Example:

Router# crypto pki server mycs reject all

Rejects all or specific SCEP requests.

Step 4

cryptopkiservercs-labelpasswordgenerateminutes

Example:

Router# crypto pki server mycs password generate 75

Generates a OTP for SCEP requests.

minutes--Length of time, in minutes, that the password is valid. Valid values range from 1 to 1440 minutes. The default is 60 minutes.

Note

Only one OTP is valid at a time; if a second OTP is generated, the previous OTP is no longer valid.

Step 5

cryptopkiservercs-labelrevokecertificate-serial-number

Example:

Router# crypto pki server mycs revoke 3

Revokes a certificate on the basis of its serial number.

certificate-serial-number--One of the following options:

A string with a leading 0x, which is treated as a hexadecimal value

A string with a leading 0 and no x, which is treated as octal

All other strings, which are treated as decimal

Step 6

cryptopkiservercs-labelrequestpkcs10
{url
|
terminal} [base64| pem

Example:

Router# crypto pki server mycs request pkcs10 terminal pem

Manually adds either a base64-encoded or PEM-formatted PKCS10 certificate enrollment request to the request database.

After the certificate is granted, it is displayed on the console terminal using base64 encoding.

pem--Specifies the certificate that is returned with PEM headers automatically added to the certificate after the certificate is granted, regardless of whether PEM headers were used in the request.

base64--Specifies the certificate that is returned without privacy-enhanced mail (PEM) headers, regardless of whether PEM headers were used in the request.

Step 7

cryptopkiservercs-labelinfocrl

Example:

Router# crypto pki server mycs info crl

Displays information regarding the status of the current CRL.

Step 8

cryptopkiservercs-labelinforequests

Example:

Router# crypto pki server mycs info requests

Displays all outstanding certificate enrollment requests.

Removing Requests from the Enrollment Request Database

After the certificate server receives an enrollment request, the server can leave the request in a pending state, reject it, or grant it. The request stays in the enrollment request database for 1 week until the client polls the certificate server for the result of the request. If the client exits and never polls the certificate server, you can remove either individual requests or all requests from the database.

Use this task to remove requests from the database and allow the server to be returned to a clean slate with respect to the keys and transaction IDs. Also, you can use this task to help troubleshoot a SCEP client that may not be behaving properly.

SUMMARY STEPS

1.enable

2.cryptopkiservercs-labelremove{all | req-id}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

cryptopkiservercs-labelremove{all | req-id}

Example:

Router# cryptopkiservermycsremove15

Removes enrollment requests from the enrollment request database.

Deleting a Certificate Server

Users can delete a certificate server from the PKI configuration if they no longer want it on the configuration. Typically, a subordinate certificate server or an RA is being deleted. However, users may delete a root certificate server if they are moving it to another device through the archived RSA keys.

Perform this task to delete a certificate server from your PKI configuration.

Note

When a certificate server is deleted, the associated trustpoint and key are also deleted.

SUMMARY STEPS

1.enable

2.configureterminal

3.nocryptopkiservercs-label

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router
> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configureterminal

Example:

Router
# configure terminal

Enters global configuration mode.

Step 3

nocryptopkiservercs-label

Example:

Router (config)# no crypto pki server mycs

Deletes a certificate server and associated trustpoint and key.

Verifying and Troubleshooting Certificate Server and CA Status

Use any of the following optional steps to verify the status of the certificate server or the CA.

SUMMARY STEPS

1.enable

2.debugcryptopkiserver

3.dirfilesystem:

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

debugcryptopkiserver

Example:

Router# debug crypto pki server

Enables debugging for a crypto PKI certificate server.

This command can be used for monitoring the progress of an enrollment and for troubleshooting if the certificate server fails to respond or if the certificate server has trouble handling the request that has been configured.

Step 3

dirfilesystem:

Example:

Router# dir slot0:

Displays a list of files on a file system.

This command can be used to verify the certificate server autoarchived file if the databaseurl command was entered to point to a local file system. You should be able to at least see "cs-label
.ser" and "cs-label
.crl" files in the database.

Verifying CA Certificate Information

To obtain information relating to the CA certificates including the certificate server rollover process, rollover certificates, and timers, you may use any of the following commands.

Note

These commands are not exclusive to shadow certificate information. If no shadow certificate exists, the following commands display the active certificate information.

SUMMARY STEPS

1.
The cryptopkicertificatechain command can be used to view the certificate chain details and to distinguish the current active certificate from the rollover certificate in the certificate chain. The following example shows a certificate chain with an active CA certificate and a shadow, or rollover, certificate:

3.
The showcryptopkicertificates command displays information about your certificate, the certification authority certificate, shadow certificates, and any registration authority certificates. The following example displays the certificate of the router and the certificate of the CA. There is no shadow certificate available. A single, general-purpose RSA key pair was previously generated, and a certificate was requested but not received for that key pair. Note that the certificate status of the router shows "Pending." After the router receives its certificate from the CA, the Status field changes to "Available" in the show output.

4.
The showcryptopkiserver command displays the current state and configuration of the certificate server. The following example shows that the certificate server "routercs" has rollover configured. The CA auto-rollover time has occurred and the rollover, or shadow, PKI certificate is available. The status shows the rollover certificate fingerprint and rollover CA certificate expiration timer information.

5.
The showcryptopkitrustpointscommand displays the trustpoints that are configured in the router. The following output shows that a shadow CA certificate is available and shows the SCEP capabilities reported during the last enrollment operation:

DETAILED STEPS

Step 1

The cryptopkicertificatechain command can be used to view the certificate chain details and to distinguish the current active certificate from the rollover certificate in the certificate chain. The following example shows a certificate chain with an active CA certificate and a shadow, or rollover, certificate:

The showcryptopkicertificates command displays information about your certificate, the certification authority certificate, shadow certificates, and any registration authority certificates. The following example displays the certificate of the router and the certificate of the CA. There is no shadow certificate available. A single, general-purpose RSA key pair was previously generated, and a certificate was requested but not received for that key pair. Note that the certificate status of the router shows "Pending." After the router receives its certificate from the CA, the Status field changes to "Available" in the show output.

The showcryptopkiserver command displays the current state and configuration of the certificate server. The following example shows that the certificate server "routercs" has rollover configured. The CA auto-rollover time has occurred and the rollover, or shadow, PKI certificate is available. The status shows the rollover certificate fingerprint and rollover CA certificate expiration timer information.

The showcryptopkitrustpointscommand displays the trustpoints that are configured in the router. The following output shows that a shadow CA certificate is available and shows the SCEP capabilities reported during the last enrollment operation:

Configuring Specific Storage and Publication Locations Examples

The following example shows the configuration of a minimal local file system, so that the certificate server can respond quickly to certificate requests. The .ser and .crl files are stored on the local Cisco IOS file system for fast access, and a copy of all of the .crt files are published to a remote location for long-term logging.

Free space on the local file system should be monitored, in case the .crl file becomes too large.

The following example shows the configuration of a primary storage location for critical files, a specific storage location for the critical file serial number file, the main certificate server database file, and a password protected file publication location for the CRL file:

Autoarchiving the Certificate Server Root Keys Examples

The following output configurations and examples show what you might see if the databasearchive command has not been configured (that is, configured using the default value); if the databasearchive command has been configured to set the CA certificate and CA key archive format as PEM, without configuring a password; and if the databasearchive command has been configured to set the CA certificate and CA key archive format as PKCS12, with a password configured. The last example is sample content of a PEM-formatted archive file.

database archive Command Not Configured

Note

The default is PKCS12, and the prompt for the password appears after the noshutdown command has been issued.

PEM-Formatted Archive

The following sample output shows that autoarchiving has been configured in PEM file format. The archive consists of the CA certificate and the CA private key. To restore the certificate server using the backup, you would have to import the PEM-formatted CA certificate and CA key individually.

Note

In addition to the CA certificate and CA key archive files, you should also back up the serial file (.ser) and the CRL file (.crl) regularly. The serial file and the CRL file are both critical for CA operation if you need to restore your certificate server.

The following example shows the configuration of "myra", an RA server, configured to support automatic rollover from "myca", the CA. After the RA server is configured, automatic granting of certificate reenrollment requests is enabled:

Enabling CA Certificate Rollover to Start Immediately Example

The following example shows how to enable automated CA certificate rollover on the server mycs with the cryptopkiservercommand. The showcryptopkiserver command then shows the current state of the mycs server and that the rollover certificate is currently available for rollover.

Where to Go Next

After the certificate server is successfully running, you can either begin enrolling clients through manual mechanisms (as explained in the modul
e "Configuring Certificate Enrollment for a PKI") or begin configuring SDP, which is a web-based enrollment interface, (as explained in the module "Setting Up Secure Device Provisioning (SDP) for Enrollment in a PKI.")

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Feature Information for the Cisco IOS Certificate Server

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 4

Feature Information for the Cisco IOS Certificate Server

Feature Name

Releases

Feature Information

Cisco IOS USB Token PKI Enhancements-- Phase 2

12.4(11)T

This feature enhances USB token functionality by using the USB token as a cryptographic device. USB tokens may be used for RSA operations such as key generation, signing, and authentication.

The following sections in this document provide information about this feature:

This document covers the use of using USB tokens for RSA operations during certificate server configuration.

IOS Certificate Server (CS) Split Database

12.4(4)T

This feature allows the user to set storage locations and publish locations for specific certificate server file types.

The following sections provide information about this feature:

The following command was modified by this feature:
databaseurl

Subordinate/RA Mode IOS Certificate Server (CS) Rollover

12.4(4)T

This feature expands on Certificate Authority (CA) Key Rollover introduced in 12.4(2)T to allow CA certificate rollover for subordinate CAs and RA-mode CAs. This functionality allows the rollover expiring CA certificates and keys and to have these changes propagate through the PKI network without manual intervention.

The following sections provide information about this feature:

The following command was modified by this feature:
grantautorollover

Certificate Authority (CA) Key Rollover

12.4(2)T

This feature introduces the ability for root or subordinate CAs to roll over expiring CA certificates and keys and to have these changes propagate through the PKI network without manual intervention.

The following sections provide information about this feature:

The following commands were introduced or modified by this feature:
auto-rollover,
cryptopkicertificatechain,cryptopkiexportpem,cryptopkiserverinforequest,cryptopkiserver,showcryptopkicertificates,showcryptopkiserver, and
showcryptopkitrustpoint

Cisco IOS Certificate Server

12.3(8)T

This feature introduces support for the Cisco IOS certificate server, which offers users a CA that is directly integrated with Cisco IOS software to more easily deploy basic PKI networks.

This enhancement enables the CA certificate and CA key to be backed up automatically just once after they are generated by the certificate server. As a result, it is not necessary to generate an exportable CA key if CA backup is desirable.

The following sections provide information about this feature:

The following commands were introduced by this feature:
cryptopkiserverremote,
databasearchive

The Certificate Server Registration Authority (RA) Mode enhancement

12.3(7)T

A certificate server can be configured to run in RA mode.

The following section provides information about this feature:

The following commands were introduced by this feature:
grantra-auto,
lifetimeenrollment-requests

PKI Status 1

12.3(11)T

This enhancement provides a quick snapshot of current trustpoint status.

The following section provides information about this enhancement:

The following command was modified by this enhancement :
showcryptopkitrustpoints

Subordinate Certificate Server 1

12.3(14)T

This enhancement allows you to configure a subordinate certificate server to grant all or certain SCEP or manual certificate requests.

The following section provides information about this enhancement:

The following command was introduced by this enhancement :
modesub-cs

RSA 4096-bit Key Generation in Software Crypto Engine Support

15.1(1)T

The range value for the
modulus keyword value for the
cryptokeygeneratersa command is extended from 360 to 2048 bits to 360 to 4096 bits.

IOS PKI Server RA Mode Support for Non-IOS CA Servers

15.1(2)T

This enhancement allows the IOS CA server in RA mode to interoperate with more than one type of CA server.

The following section provides information about this feature:

The
transparent keyword was added to the
modera command to allow the CA server in RA mode to interoperate with more than one type of CA server.

Public Key Infrastructure (PKI) IPv6 Support for VPN Solutions

15.2(1)T

The
enrollment url (ca-trustpoint) command was modified to allow the specification of an IPv6 address in the URL for the CA.

1 This is a minor enhancement. Minor enhancements are not typically listed in Feature Navigator.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:
www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.