Configuring and Managing a Certificate Server for PKI Deployment

Configuring and Managing a Certificate Server

for PKI Deployment

This module describes how to set up and manage a Cisco IOS certiﬁcate server for public key infrastructure

(PKI) deployment. A certiﬁcate server embeds a simple certiﬁcate server, with limited certiﬁcation authority

(CA) functionality, into the Cisco software. Thus, the following beneﬁts are provided to the user:

• Easier PKI deployment by deﬁning default behavior. The user interface is simpler because default

behaviors are predeﬁned. That is, you can leverage the scaling advantages of PKI without all of the

certiﬁcate extensions that a CA provides, thereby allowing you to easily enable a basic PKI-secured

network.

• Direct integration with Cisco software.

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.

Note

During copy, if running-conﬁg has both CA and ID certiﬁcates, if CA certiﬁcate is same as running-conﬁg,

CA and ID are not replaced. Whereas, if CA certiﬁcate is different, then both ID and CA certiﬁcates gets

cleared and new CA is re-inserted.

• Prerequisites for Conﬁguring a Certiﬁcate Server, on page 2

• Restrictions for Conﬁguring a Certiﬁcate Server, on page 2

• Information About Certiﬁcate Servers, on page 3

• How to Set Up and Deploy a Certiﬁcate Server, on page 10

• Conﬁguration Examples for Using a Certiﬁcate Server, on page 37

• Where to Go Next, on page 48

• Additional References for Conﬁguring and Managing a Certiﬁcate Server for PKI Deployment, on page

• Feature Information for Conﬁguring and Managing a Certiﬁcate Server for PKI Deployment, on page

Configuring and Managing a Certificate Server for PKI Deployment

Prerequisites for Configuring a Certificate Server

Planning Your PKI Before Configuring the Certificate Server

Before conﬁguring a certiﬁcate 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 certiﬁcate lifetimes and certiﬁcate revocation list

(CRL) lifetimes). After the settings have been conﬁgured in the certiﬁcate server and certiﬁcates have been

granted, settings cannot be changed without having to reconﬁgure the certiﬁcate server and reenrolling the

peers. For information on certiﬁcate server default settings and recommended settings, see section “Certiﬁcate

Server Default Values and Recommended Values.”

Enabling an HTTP Server

The certiﬁcate server supports Simple Certiﬁcate Enrollment Protocol (SCEP) over HTTP. The HTTP server

must be enabled on the router for the certiﬁcate server to use SCEP. (To enable the HTTP server, use the ip

http server command.) The certiﬁcate serverautomatically 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.

To take advantage of automatic CA certiﬁcate and key pair rollover functionality for all types of certiﬁcate

servers, SCEP must be used as the enrollment method.

Note

Configuring Reliable Time Services

Time services must be running on the router because the certiﬁcate server must have reliable time knowledge.

If a hardware clock is unavailable, the certiﬁcate server depends on manually conﬁgured 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 certiﬁcate server automatically switches to running status.

For information on manually conﬁguring clock settings, see the module .

Restrictions for Configuring a Certificate Server

• The certiﬁcate server does not provide a mechanism for modifying the certiﬁcate request that is received

from the client; that is, the certiﬁcate that is issued from the certiﬁcate server matches the requested

certiﬁcate without modiﬁcations. If a speciﬁc certiﬁcate policy, such as name constraints, must be issued,

the policy must be reﬂected in the certiﬁcate request.

•

• For validating the HTTP connection using 3rd party open SSL, the complete ISE certiﬁcate chain is sent

to the device. These certiﬁcates include the ISE certiﬁcate and its issuer CA certiﬁcate. The environment

data lists these certiﬁcates.

Cisco ISE running versions 2.7.0.310 and earlier put the certiﬁcate chain in the incoming certiﬁcate list

as part of environment data. In Cisco IOS XE Release 17.1.1 and earlier releases, Cisco routers do not

Configuring and Managing a Certificate Server for PKI Deployment

Prerequisites for Configuring a Certificate Server

support multi-chain certiﬁcate downloads from ISE. Due to this, the device does not receive the ISE

certiﬁcate and a TLS handshake error is displayed.

Information About Certificate Servers

RSA Key Pair and Certificate of the Certificate Server

The certiﬁcate 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 Certiﬁcate Server RSA Key Pair .”

The recommended modulus for a certiﬁcate server RSA key pair is 2048 bits.

Note

The certiﬁcate server uses a regular RSA key pair as its CA key. This key pair must have the same name as

the certiﬁcate server. If you do not generate the key pair before the certiﬁcate server is created on the router,

a general-purpose key pair is automatically generated during the conﬁguration of the certiﬁcate server.

The CA certiﬁcate and CA key can be backed up automatically one time after they are generated by the

certiﬁcate 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

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 Certiﬁcate Server RSA Key Pair .”

How the CA Certificate and CA Key Are Automatically Archived

At initial certiﬁcate server setup, you can enable the CA certiﬁcate and the CA key to be automatically archived

so that they may be restored later if either the original copy or the original conﬁguration is lost.

When the certiﬁcate server is turned on the ﬁrst time, the CA certiﬁcate and CA key is generated. If automatic

archive is also enabled, the CA certiﬁcate and the CA key is exported (archived) to the server database. The

archive can be in PKCS12 or privacy-enhanced mail (PEM) format.

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

Note

• 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 certiﬁcate 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 certiﬁcate and CA key archive ﬁle, you should also regularly back up the serial

number ﬁle (.ser) and the CRL ﬁle (.crl). The serial ﬁle and the CRL ﬁle are both critical for CA operation

if you need to restore your certiﬁcate server.

Configuring and Managing a Certificate Server for PKI Deployment

Information About Certificate Servers

• 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 certiﬁcate server stores ﬁles for its own use and may publish ﬁles for other processes to use. Critical ﬁles

generated by the certiﬁcate server that are needed for its ongoing operation are stored to only one location

per ﬁle type for its exclusive use. The certiﬁcate server reads from and writes to these ﬁles. The critical

certiﬁcate server ﬁles are the serial number ﬁle (.ser) and the CRL storage location ﬁle (.crl). Files that the

certiﬁcate server writes to, but does not read from again, may be published and available for use by other

processes. An example of a ﬁle that may be published is the issued certiﬁcates ﬁle (.crt).

Performance of your certiﬁcate server may be affected by the following factors, which should be considered

when you choose storage options and publication options for your certiﬁcate server ﬁles.

• The storage or publish locations you choose may affect your certiﬁcate server performance. Reading

from a network location takes more time than reading directly from a router’s local storage device.

• The number of ﬁles you choose to store or publish to a speciﬁc location may affect your certiﬁcate server

performance. The local ﬁle system may not always be suitable for a large number of ﬁles.

• The ﬁle types you choose to store or publish may affect your certiﬁcate server performance. Certain

ﬁles, such as the .crl ﬁles, can become very large.

It is recommended that you store .ser and .crl ﬁles to your local ﬁle system and publish your .crt ﬁles to a

remote ﬁle system.

Note

Certificate Server Database File Storage

The certiﬁcate server allows the ﬂexibility to store different critical ﬁle types to different storage locations

depending on the database level set (see the database level command for more information). When choosing

storage locations, consider the ﬁle security needed and server performance. For instance, serial number ﬁles

and archive ﬁles (.p12 or .pem) might have greater security restrictions than the issued certiﬁcates ﬁle storage

location (.crt) or the name ﬁle storage location (.cnm).

The table below shows the critical certiﬁcate server ﬁle types by ﬁle extension that may be stored to a speciﬁc

location.

Table 1: Certificate Server Storage Critical File Types

File TypeFile Extension

The main certiﬁcate server database ﬁle..ser

The CRL storage location..crl

The issued certiﬁcates storage location..crt

The certiﬁcate name and expiration ﬁle storage location..cnm

Configuring and Managing a Certificate Server for PKI Deployment

Certificate Server Database

File TypeFile Extension

The certiﬁcate server certiﬁcate archive ﬁle location in PKCS12 format..p12

The certiﬁcate server certiﬁcate archive ﬁle location in PEM format..pem

certiﬁcate server ﬁles may be stored to three levels of speciﬁcity:

• Default location, NVRAM

• Speciﬁed primary storage location for all critical ﬁles

• Speciﬁed storage location for speciﬁc critical ﬁle(s).

A more speciﬁc storage location setting overrides a more general storage location setting. For instance, if you

have not speciﬁed any certiﬁcate server ﬁle storage locations, all certiﬁcate server ﬁles are stored to NVRAM.

If you specify a storage location for the name ﬁle, only the name ﬁle is stored there; all other ﬁles continue

to be stored to NVRAM. If you then specify a primary location, all ﬁles except the name ﬁle is now stored

to this location, instead of NVRAM.

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

Note

Certificate Server Database File Publication

A publish ﬁle is a copy of the original ﬁle and is available for other processes to use or for your use. If the

certiﬁcate server fails to publish a ﬁle, it does cause the server to shut down. You may specify one publish

location for the issued certiﬁcates ﬁle and name ﬁle and multiple publish locations for the CRL ﬁle. See the

table below for ﬁles types available for publication. You may publish ﬁles regardless of the database level

that is set.

Table 2: Certificate Server Publish File Types

File TypeFile Extension

The CRL publish location..crl

The issued certiﬁcates publish location..crt

The certiﬁcate name and expiration ﬁle publish location..cnm

Trustpoint of the Certificate Server

If the certiﬁcate server also has an automatically generated trustpoint of the same name, then the trustpoint

stores the certiﬁcate of the certiﬁcate server. After the router detects that a trustpoint is being used to store

the certiﬁcate of the certiﬁcate server, the trustpoint is locked so that it cannot be modiﬁed.

Before conﬁguring the certiﬁcate server you can perform the following:

• Manually create and set up this trustpoint (using the crypto pki trustpointcommand), which allows you

to specify an alternative RSA key pair (using the rsakeypair command).

Configuring and Managing a Certificate Server for PKI Deployment

Certificate Server Database File Publication

• Specify that the initial autoenrollment key pair is generated on a speciﬁc device, such as a conﬁgured

and available USB token, using the on command.

The automatically generated trustpoint and the certiﬁcate server certiﬁcate are not available for the certiﬁcate

server device identity. Thus, any command-line interface (CLI) (such as the ip http secure-trustpoint

command) that is used to specify the CA trustpoint to obtain certiﬁcates and authenticate the connecting

client’s certiﬁcate must point to an additional trustpoint conﬁgured on the certiﬁcate server device.

Note

If the server is a root certiﬁcate server, it uses the RSA key pairs and several other attributes to generate a

self-signed certiﬁcate. The associated CA certiﬁcate has the following key usage extensions--Digital Signature,

Certiﬁcate Sign, and CRL Sign.

After the CA certiﬁcate is generated, attributes can be changed only if the certiﬁcate server is destroyed.

A certiﬁcate server trustpoint must not be automatically enrolled using the auto-enroll command. Initial

enrollment of the certiﬁcate server must be initiated manually and ongoing automatic rollover functionality

may be conﬁgured with the auto-rollover command.

Note

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 lifetime crl command. After the CRL is issued, it is written to the

speciﬁed database location as ca-label.crl, where ca-label is the name of the certiﬁcate server.

CRLs can be distributed through SCEP, which is the default method, or a CRL distribution point (CDP), if

conﬁgured and available. If you set up a CDP, use the cdp-url command to specify the CDP location. If the

cdp-url command is not speciﬁed, the CDP certiﬁcate extension is not included in the certiﬁcates that are

issued by the certiﬁcate server. If the CDP location is not speciﬁed, Cisco IOS PKI clients automatically

request a CRL from the certiﬁcate 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 certiﬁcate 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/ﬁlename.crl

The certiﬁcate server supports only one CDP; thus, all certiﬁcates 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 conﬁgure the CDP

to point to that server. Or, you can specify a non-SCEP request for the retrieval of the CRL from the certiﬁcate

server by specifying the cdp-url command with the URL in the following format where cs-addr is the location

of the certiﬁcate server:

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

Configuring and Managing a Certificate Server for PKI Deployment

Certificate Revocation Lists (CRLs)

If your CA is also conﬁgured as your HTTP CDP server, specify your CDP with the cdp-url

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

Note

It is the responsibility of the network administrator to ensure that the CRL is available from the location that

is speciﬁed through the cdp-url command.

In order to force the parser to retain the embedded question mark within the speciﬁed 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 certiﬁcate server is running through the cdp-url command. New

certiﬁcates contain the updated CDP location, but existing certiﬁcates are not reissued with the newly speciﬁed

CDP location. When a new CRL is issued, the certiﬁcate server uses its current cached CRL to generate a

new CRL. (When the certiﬁcate 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 certiﬁcate is revoked from the CLI.

Certificate Server Error Conditions

At startup, the certiﬁcate server checks the current conﬁguration before issuing any certiﬁcates. It reports the

last known error conditions through theshow crypto pki server command output. Example errors can include

any of the following conditions:

• Storage inaccessible

• Waiting for HTTP server

• Waiting for time setting

If the certiﬁcate server experiences a critical failure at any time, such as failing to publish a CRL, the certiﬁcate

server automatically enters a disabled state. This state allows the network administrator to ﬁx the condition;

thereafter, the certiﬁcate server returns to the previous normal state.

Certificate Enrollment Using a Certificate Server

A certiﬁcate enrollment request functions as follows:

• The certiﬁcate 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 certiﬁcate enrollment request states.)

• The certiﬁcate server refers to the CLI conﬁguration (or the default behavior any time a parameter

is not speciﬁed) 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 certiﬁcate 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 certiﬁcate and stores the certiﬁcate in the enrollment request

database.

If the connection of the client has closed, the certiﬁcate server waits for the client to request another certiﬁcate.

Configuring and Managing a Certificate Server for PKI Deployment

Certificate Server Error Conditions

All enrollment requests transition through the certiﬁcate enrollment states that are deﬁned in the table below.

To see current enrollment requests, use the crypto pki server request pkcs10 command.

Table 3: Certificate Enrollment Request State Descriptions

DescriptionCertificate Enrollment State

The certiﬁcate server has authorized the request.authorized

The certiﬁcate server has denied the request for policy reasons.denied

The CA core has generated the appropriate certiﬁcate for the certiﬁcate request.granted

The request has been created by the SCEP server.initial

The certiﬁcate server has determined that the request is invalid for cryptographic

reasons.

malformed

The enrollment request must be manually accepted by the network

administrator.

pending

SCEP Enrollment

All SCEP requests are treated as new certiﬁcate enrollment requests, even if the request speciﬁes a duplicate

subject name or public key pair as a previous certiﬁcate request.

Types of CA Servers Subordinate and Registration Authorities (RAs)

CA servers have the ﬂexibility to be conﬁgured as a subordinate certiﬁcate server or an RA-mode certiﬁcate

server.

Why Configure a Subordinate CA?

A subordinate certiﬁcate server provides all the same features as a root certiﬁcate server. The root RSA key

pairs are extremelyimportant in a PKI hierarchy, and it is often advantageous to keep them ofﬂine 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 ofﬂine (except to issue occasional CRL updates), and

the subordinate CA can be used during normal operation.

Why Configure an RA-Mode Certificate Server?

A certiﬁcate server can be conﬁgured to run in RA mode. An RA ofﬂoads 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 certiﬁcate and return it to the RA. The client can later retrieve

the granted certiﬁcate 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

certiﬁcates. 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 certiﬁcates and CRLs.

Configuring and Managing a Certificate Server for PKI Deployment

SCEP Enrollment

CA Server Compatibility

The CA server compatibility allows the IOS CA server in RA mode to interoperate with more than one type

of CA server. For more information, see “Conﬁguring a Certiﬁcate Server to Run in RA Mode.”

Automatic CA Certificate and Key Rollover

CAs--root CAs, subordinate CAs, and RA-mode CAs--like their clients, have certiﬁcates and key pairs with

expiration dates that need to be reissued when the current certiﬁcate and key pair are about to expire. When

a root CA’s certiﬁcate and key pair are expiring it must generate a self-signed rollover certiﬁcate and key

pair. If a subordinate CA or an RA-mode CA’s certiﬁcate and key pair are expiring, it requests a rollover

certiﬁcate and key pair from its superior CA, obtaining the superior CA’s new self-signed rollover certiﬁcates

at the same time. The CA must distribute the new CA rollover certiﬁcate 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 certiﬁcate and key pair to a new CA certiﬁcate 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 certiﬁcate 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 conﬁgured. 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 Certiﬁcate Enrollment ” in the

chapter “Conﬁguring Certiﬁcate Enrollment for a PKI”.

After CAs have rollover enabled and their clients are automatically enrolled, there are three stages to the

automatic CA certiﬁcate rollover process.

Stage One: Active CA Certificate and Key Pair Only

In stage one, there is an active CA certiﬁcate and key pair only.

Stage Two: Rollover CA Certificate and Key Pair Generation and Distribution

In stage two, the rollover CA certiﬁcate and key pair are generated and distributed. The superior CA generates

a rollover certiﬁcate and key pair. After the CA successfully saves its active conﬁguration, the CA is ready

to respond to client requests for the rollover certiﬁcate and key pair. When the superior CA receives a request

for the new CA certiﬁcate and key pair from a client, the CA responds by sending the new rollover CA

certiﬁcate and key pair to the requesting client. The clients store the rollover CA certiﬁcate and key pair.

When a CA generates its rollover certiﬁcate and key pair, it must be able to save its active conﬁguration. If

the current conﬁguration has been altered, saving of the rollover certiﬁcate and key pair does not happen

automatically. In this case, the administrator must save the conﬁguration manually or rollover information is

lost.

Note

Configuring and Managing a Certificate Server for PKI Deployment

Automatic CA Certificate and Key Rollover

Stage Three: Rollover CA Certificate and Key Pair Become the Active CA Certificate and Key Pair

In stage three, the rollover CA certiﬁcate and key pair become the active CA certiﬁcate and key pair. All

devices that have stored a valid rollover CA certiﬁcate rename the rollover certiﬁcate to the active certiﬁcate

and the once-active certiﬁcate and key pair are deleted.

After the CA certiﬁcate rollover, you may observe the following deviation from usual certiﬁcate lifetime and

renewal time:

• The lifetime of the certiﬁcates issued during rollover is lower than the preconﬁgured value.

• In speciﬁc conditions, the renew time may be inferior to the conﬁgured percentage of the actual lifetime.

The difference observed can be of up to 20% in cases where the certiﬁcate lifetime is less than one hour.

These differences are normal, and result from jitter (random time ﬂuctuation) introduced by the algorithm

on the Certiﬁcate server. This task is performed to avoid the hosts participating to the PKI synchronize their

enrollment timer, which could result in congestion on the Certiﬁcate Server.

The lifetime ﬂuctuations that occur do not affect proper functionning of the PKI, since the differences always

result in a shorter lifetime, thus remaining within maximum conﬁgured lifetime for certiﬁcates.

Note

Support for Specifying a Cryptographic Hash Function

Secure Hash Algorithm (SHA) support allows a user to specify a cryptographic hash function for Cisco IOS

XE certiﬁcate servers and clients. The cryptographic hash functions that can be speciﬁed are Message Digest

algorithm 5 (MD5), SHA-1, SHA-256, SHA-384, or SHA-512.

Cisco no longer recommends using MD5; instead, you should use SHA-256 where supported. For more

information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE)

white paper.

Note

See the “Conﬁguring a Subordinate Certiﬁcate Server” task for more information on specifying the hash

(ca-trustpoint) and hash (cs-server) commands that are used to implement this feature.

How to Set Up and Deploy a Certificate Server

Generating a Certificate Server RSA Key Pair

Perform this task to manually generate an RSA key pair for the certiﬁcate server. Manually generating a

certiﬁcate 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.

Configuring and Managing a Certificate Server for PKI Deployment

Support for Specifying a Cryptographic Hash Function

You may want to create an exportable certiﬁcate server key pair for backup, or archive purposes. If this task

is not performed, the certiﬁcate server automatically generates a key pair, which is not marked as exportable.

Note

If your device has a USB token conﬁgured 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 speciﬁc documents

about conﬁguring a USB token and making it available to use as a cryptographic device, see the “Related

Documents” section.

It is recommended that the private key be kept in a secure location and that you regularlyarchive the certiﬁcate

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.

Note

SUMMARY STEPS

1. enable

2. conﬁgure terminal

3. crypto key generate rsa [general-keys | usage-keys | signature | encryption] [label key-label]

[exportable] [modulus modulus-size] [storage devicename:] [on devicename:]

4. crypto key export rsa key-label pem {terminal | url url} {3des | des} passphrase

5. crypto key import rsa key-label pem [usage-keys | signature | encryption] {terminal | url url}

[exportable] [on devicename:] passphrase

6. exit

7. show crypto key mypubkey rsa

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Enters global conﬁguration mode.conﬁgure terminal

Example:

Step 2

Device# configure terminal

Generates the RSA key pair for the certiﬁcate server.crypto key generate rsa [general-keys | usage-keys |

signature | encryption] [label key-label] [exportable]

Step 3

Configuring and Managing a Certificate Server for PKI Deployment

Generating a Certificate Server RSA Key Pair

PurposeCommand or Action

[modulus modulus-size] [storage devicename:] [on

devicename:]

• The storage keyword speciﬁes the key storage

location.

Example:

• When specifying a label name by specifying the

key-label argument, you must use the same name for

Device(config)# crypto key generate rsa label mycs

exportable modulus 2048

the label that you plan to use for the certiﬁcate server

(through the crypto pki server cs-labelcommand). If

a key-label argument is not speciﬁed, the default value,

which is the fully qualiﬁed domain name (FQDN) of

the router, is used.

If the exportable RSA key pair is manually generated after

the CA certiﬁcate has been generated, and before issuing

the no shutdown command, then use the crypto ca export

pkcs12 command to export a PKCS12 ﬁle that contains the

certiﬁcate server certiﬁcate and the private key.

• By default, the modulus size of a CA RSA key is 1024

bits. The recommended modulus for a CA RSA key

is 2048 bits. The range for a modulus size of a CA

RSA key is from 350 to 4096 bits.

• The on keyword speciﬁes that the RSA key pair is

created on the speciﬁed device, including a Universal

Serial Bus (USB) token, local disk, or NVRAM. The

name of the device is followed by a colon (:).

Keys created on a USB token must be 2048 bits

or less.

Note

(Optional) Exports the generated RSA key pair.crypto key export rsa key-label pem {terminal | url

url} {3des | des} passphrase

Step 4

Allows you to export the generated keys.

Example:

Device(config)# crypto key export rsa mycs pem url

nvram: 3des PASSWORD

(Optional) Imports RSA key pair.crypto key import rsa key-label pem [usage-keys |

signature | encryption] {terminal | url url} [exportable]

[on devicename:] passphrase

Step 5

To create the imported keys on a USB token, use the on

keyword and specify the appropriate device location.

Example:

If you exported the RSA keys using the exportable keyword

and you want to change the RSA key pair to nonexportable

Device(config)# crypto key import rsa mycs2 pem

url nvram:mycs PASSWORD

, import the key back to the certiﬁcate server without the

exportable keyword. The key cannot be exported again.

Exits global conﬁguration.exit

Example:

Step 6

Device(config)# exit

Configuring and Managing a Certificate Server for PKI Deployment

Generating a Certificate Server RSA Key Pair

PurposeCommand or Action

Displays the RSA public keys of your router.show crypto key mypubkey rsa

Example:

Step 7

Device# show crypto key mypubkey rsa

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:

Device(config)# crypto key generate rsa on usbtoken0 label ms2 modulus 2048

The name for the keys will be: ms2

% The key modulus size is 2048 bits

% Generating 2048 bit RSA keys, keys will be on-token, non-exportable...

Jan 7 02:41:40.895: crypto_engine: Generate public/private keypair [OK]

Jan 7 02:44:09.623: crypto_engine: Create signature

Jan 7 02:44:10.467: crypto_engine: Verify signature

Jan 7 02:44:10.467: CryptoEngine0: CRYPTO_ISA_RSA_CREATE_PUBKEY(hw)(ipsec)

Jan 7 02:44:10.467: CryptoEngine0: CRYPTO_ISA_RSA_PUB_DECRYPT(hw)(ipsec)

Now, the on-token keys labeled “ms2” may be used for enrollment.

The following example shows the successful import of an encryption key to a conﬁgured and available

USB tokens:

Device# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Device(config)# crypto key import rsa encryption on usbtoken0 url nvram:e password

% Importing public Encryption key or certificate PEM file...

filename [e-encr.pub]?

Reading file from nvram:e-encr.pub

% Importing private Encryption key PEM file...

Source filename [e-encr.prv]?

Reading file from nvram:e-encr.prv

% Key pair import succeeded.

Configuring Certificate Servers

Prerequisites for Automatic CA Certificate Rollover

When conﬁguring a certiﬁcate server, for automatic CA certiﬁcate rollover to run successfully, the following

prerequisites are applicable for your CA servers:

• Your CA server must be enabled and fully conﬁgured with a reliable time of day, an available key pair,

a self-signed, valid CA certiﬁcate 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 certiﬁcate server.

Configuring and Managing a Certificate Server for PKI Deployment

Configuring Certificate Servers

Restrictions for Automatic CA Certificate Rollover

When conﬁguring a certiﬁcate server, in order for automatic CA certiﬁcate 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 certiﬁcate management protocol or mechanism (such as enrollment proﬁles, manual

enrollment, or TFTP enrollment) is not be able to take advantage of the rollover functionality provided

by SCEP.

• If you have automatic archive conﬁgured on your network and the archive fails, rollover does not occur

because the certiﬁcate server does not enter the rollover state, and the rollover certiﬁcate and key pair

is not automatically saved.

Configuring a Certificate Server

Perform this task to conﬁgure a certiﬁcate server and enable automatic rollover.

SUMMARY STEPS

1. enable

2. conﬁgure terminal

3. ip http server

4. crypto pki server cs-label

5. no shutdown

6. auto-rollover [time-period]

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Enters global conﬁguration mode.conﬁgure terminal

Example:

Step 2

Device# configure terminal

Enables the HTTP server on your system.ip http server

Example:

Step 3

Device(config)# ip http server

Deﬁnes a label for thecertiﬁcate server and enters certiﬁcate

server conﬁguration mode.

crypto pki server cs-label

Example:

Step 4

If you manually generated an RSA key pair, the

cs-label argument must match the name of the

key pair.

Note

Device(config)# crypto pki server server-pki

(Optional) Enables the certiﬁcate server.no shutdown

Step 5

Configuring and Managing a Certificate Server for PKI Deployment

Restrictions for Automatic CA Certificate Rollover

PurposeCommand or Action

Example:

Only use this command at this point if you want

to use the preconﬁgured default functionality.

That is, do not issue this command just yet if you

plan to change any of the default settings as

shownin the task “Conﬁguring Certiﬁcate Server

Functionality.”

Note

Device(cs-server)# no shutdown

(Optional) Enables the automated CA certiﬁcate rollover

functionality.

auto-rollover [time-period]

Example:

Step 6

• time-period—default is 30 days.

Device(cs-server)# auto-rollover 90

Examples

The following example shows how to conﬁgure the certiﬁcate server “ms2” where ms2 is the label

of a 2048-bit RSA key pair:

Device(config)# crypto pki server ms2

Device(cs-server)# no shutdown

% Once you start the server, you can no longer change some of

% the configuration.

Are you sure you want to do this? [yes/no]:

yes

% Certificate Server enabled.

Device(cs-server)# end

Device# show crypto pki server ms2

Certificate Server ms2:

Status: enabled, configured

CA cert fingerprint: 5A856122 4051347F 55E8C246 866D0AC3

Granting mode is: manual

Last certificate issued serial number: 0x1

CA certificate expiration timer: 19:44:57 GMT Oct 14 2006

CRL NextUpdate timer: 19:45:25 GMT Oct 22 2003

Current storage dir: nvram:

Database Level: Complete - all issued certs written as <serialnum>.cer

The following example shows how to enable automated CA certiﬁcate rollover on the server ms2

with the auto-rollover command. The show crypto pki servercommand shows that the automatic

rollover has been conﬁgured on the server mycs with an overlap period of 25 days.

Device(config)# crypto pki server ms2

Device(cs-server)# auto-rollover 25

Device(cs-server)# no shutdown

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

% Exporting Certificate Server signing certificate and keys...

% Certificate Server enabled.

Device(cs-server)#

Device# show crypto pki server ms2

Certificate Server ms2:

Status:enabled

Server's configuration is locked (enter "shut" to unlock it)

Issuer name:CN=mycs

CA cert fingerprint:70AFECA9 211CDDCC 6AA9D7FF 3ADB03AE

Granting mode is:manual

Configuring and Managing a Certificate Server for PKI Deployment

Configuring a Certificate Server

Last certificate issued serial number:0x1

CA certificate expiration timer:00:49:26 PDT Jun 20 2008

CRL NextUpdate timer:00:49:29 PDT Jun 28 2005

Current storage dir:nvram:

Database Level:Minimum - no cert data written to storage

Auto-Rollover configured, overlap period 25 days

Autorollover timer:00:49:26 PDT May 26 2008

Configuring a Subordinate Certificate Server

Perform this task to conﬁgure a subordinate certiﬁcate server to grant all or certain SCEP or manual certiﬁcate

requests and to enable automatic rollover.

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.

Note

Before you begin

• The root certiﬁcate server should be a Cisco IOS XE certiﬁcate server.

• For a subordinate certiﬁcate authority (CA), enrollment to the root CA or upstream CA is possible only

through SCEP. The upstream CA must be online for the enrollment to the upstream CA to complete.

Manual enrollment of subordinate CA to the root CA or upstream CA is not possible.

SUMMARY STEPS

1. enable

2. conﬁgure terminal

3. crypto pki trustpoint name

4. enrollment [mode] [retry period minutes] [retry count number] url url [pem]

5. hash {md5 | sha1 | sha256 | sha384 | sha512}

6. exit

7. crypto pki server cs-label

8. issuer name DN-string

9. mode sub-cs

10. auto-rollover [time-period]

11. grant auto rollover {ca-cert | ra-cert}

12. hash {md5 | sha1 | sha256 | sha384 | sha512}

13. no shutdown

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Configuring and Managing a Certificate Server for PKI Deployment

Configuring a Subordinate Certificate Server

PurposeCommand or Action

Enters global conﬁguration mode.conﬁgure terminal

Example:

Step 2

Device# configure terminal

Declares the trustpoint that your subordinate certiﬁcate

server should use and enters ca-trustpoint conﬁguration

mode.

crypto pki trustpoint name

Example:

Device(config)# crypto pki trustpoint sub

Step 3

Speciﬁes the following enrollment parameters of the CA:enrollment [mode] [retry period minutes] [retry count

number] url url [pem]

Step 4

• (Optional) The mode keyword speciﬁes the

registration authority (RA) mode, if your CA system

provides an RA. By default, RA mode is disabled.

Example:

Device(ca-trustpoint)# enrollment url

http://caserver.myexample.com

• (Optional) The retry period keyword and minutes

argument speciﬁes the period, in minutes, in which

- or-

Device(ca-trustpoint)# enrollment url

http://[2001:DB8:1:1::1]:80

the router waits before sending the CA another

certiﬁcate request. Valid values are from 1 to 60. The

default is 1.

• (Optional) The retry count keyword and number

argument speciﬁes the number of times a router will

resend a certiﬁcate 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 certiﬁcate requests.

An IPv6 address can be added to the http:

enrollment 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.

Note

• (Optional) The pem keyword adds privacy-enhanced

mail (PEM) boundaries to the certiﬁcate request.

(Optional) Speciﬁes the hash function for the signature

that the Cisco IOS XE client uses to sign its self-signed

hash {md5 | sha1 | sha256 | sha384 | sha512}

Example:

Step 5

certiﬁcates. The Cisco IOS XE client uses the MD5

Device(ca-trustpoint)# hash sha384

cryptographic hash function for self-signed certiﬁcates by

default.

Any of the followingcommand algorithm keyword options

can be speciﬁed to over-ride the default setting for the

trustpoint. This setting then becomes the default

Configuring and Managing a Certificate Server for PKI Deployment

Configuring a Subordinate Certificate Server

PurposeCommand or Action

cryptographic hash algorithm function for self-signed

certiﬁcates by default.

• md5 —Speciﬁes that MD5, the default hash function,

is used. (No longer recommended).

• sha1 —Speciﬁes that the SHA-1 hash function is

used as the default hash algorithm for RSA keys. (No

longer recommended).

• sha256 —Speciﬁes that the SHA-256 hash function

is used as the hash algorithm for Elliptic Curve (EC)

256 bit keys.

• sha384 —Speciﬁes that the SHA-384 hash function

is used as the hash algorithm for EC 384 bit keys.

• sha512 —Speciﬁes that the SHA-512 hash function

is used as the hash algorithm for EC 512 bit keys.

Exits ca-trustpoint conﬁguration mode.exit

Example:

Step 6

Device(ca-trustpoint)# exit

Enables a Cisco IOS XE certiﬁcate server and enters

cs-server conﬁguration mode.

crypto pki server cs-label

Example:

Step 7

The subordinate server must have the same

name as the trustpoint that was created in Step

3 above.

Note

Device(config)# crypto pki server sub

(Optional) Speciﬁes the DN as the CA issuer name for the

certiﬁcate server.

issuer name DN-string

Example:

Step 8

Device(cs-server)# issuer-name CN=sub CA, O=Cisco,

C=us

Places the PKI server into sub-certiﬁcate server mode.mode sub-cs

Step 9

Example:

• Sub CA and CA relationship is supported only when

all the devices on the network are of Cisco IOS XE

Device(cs-server)# mode sub-cs

device type. Hence a Cisco IOS XE sub CA cannot

enroll to a third party CA server.

(Optional) Enables the automated CA certiﬁcate rollover

functionality.

auto-rollover [time-period]

Example:

Step 10

• time-period --default is 30 days.

Device(cs-server)# auto-rollover 90

(Optional) Automatically grants reenrollment requests for

subordinate CAs and RA-mode CAs without operator

intervention.

grant auto rollover {ca-cert | ra-cert}

Example:

Device(cs-server)# grant auto rollover ca-cert

Step 11

Configuring and Managing a Certificate Server for PKI Deployment

Configuring a Subordinate Certificate Server

PurposeCommand or Action

• ca-cert --Speciﬁes that the subordinate CA rollover

certiﬁcate is automatically granted.

• ra-cert --Speciﬁes that the RA-mode CA rollover

certiﬁcate is automatically granted.

If this is the ﬁrst time that a subordinate

certiﬁcate server is enabled and enrolled, the

certiﬁcate request must be manually granted.

Note

(Optional) Sets the hash function for the signature that the

Cisco IOS XE certiﬁcate authority (CA) uses to sign all

of the certiﬁcates issued by the server.

hash {md5 | sha1 | sha256 | sha384 | sha512}

Example:

Device(cs-server)# hash sha384

Step 12

• md5 —Speciﬁes that MD5, the default hash function,

is used. (No longer recommended).

• sha1 —Speciﬁes that the SHA-1 hash function is

used. (No longer recommended).

• sha256 —Speciﬁes that the SHA-256 hash function

is used.

• sha384 —Speciﬁes that the SHA-384 hash function

is used.

• sha512 —Speciﬁes that the SHA-512 hash function

is used.

Enables or reenables the certiﬁcate server.no shutdown

Step 13

Example:

If this is the ﬁrst time that a subordinate certiﬁcate server

is enabled, the certiﬁcate server generates the key and

obtain its signing certiﬁcate from the root certiﬁcate server.

Device(cs-server)# no shutdown

Examples

If the certiﬁcate server fails to enable or if the certiﬁcate server has trouble handling the request that has been

conﬁgured, you can use the debug crypto pki server command to troubleshoot your conﬁguration as shown

in the following below (Clock Not Set and Trustpoint Not Conﬁgured). Here, "ms2" refers to the label of a

2048-bit RSA key pair.

Router# debug crypto pki server

Clock Not Set

Router(config)# crypto pki server ms2

Router(cs-server)# mode sub-cs

Router(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:

*Jan 6 20:57:37.667: CRYPTO_CS: enter FSM: input state initial, input signal no shut

Configuring and Managing a Certificate Server for PKI Deployment

Examples

Re-enter password:

*Jan 6 20:57:45.303: CRYPTO_CS: starting enabling checks

*Jan 6 20:57:45.303: CRYPTO_CS: key 'sub' does not exist; generated automatically[OK]

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

Trustpoint Not Configured

Router(config)# crypto pki server ms2

Router(cs-server)# mode sub-cs

Router(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:

Jan 6 21:00:15.961: CRYPTO_CS: enter FSM: input state initial, input signal no shut.

Jan 6 21:03:34.309: CRYPTO_CS: enter FSM: input state initial, input signal time set.

Jan 6 21:03:34.313: CRYPTO_CS: exit FSM: new state initial.

Jan 6 21:03:34.313: CRYPTO_CS: cs config has been unlocked

Re-enter password:

Jan 6 21:03:44.413: CRYPTO_CS: starting enabling checks

Jan 6 21:03:44.413: CRYPTO_CS: associated trust point 'sub' does not exist; generated

automatically

Jan 6 21:03:44.417: CRYPTO_CS: key 'sub' does not exist; generated automatically[OK]

Jan 6 21:04:03.993: CRYPTO_CS: nvram filesystem

Jan 6 21:04:04.077: CRYPTO_CS: serial number 0x1 written.

You must specify an enrollment URL for this CA before you can authenticate it.

% Failed to authenticate the Certificate Authority

If the certiﬁcate server fails to obtain its signing certiﬁcate from the root certiﬁcate server, you can use the

debug crypto pki transactionscommand to troubleshoot your conﬁguration as shown in the following

example:

Router# debug crypto pki transactions

Jan 6 21:07:00.311: CRYPTO_CS: enter FSM: input state initial, input signal time set

Jan 6 21:07:00.311: CRYPTO_CS: exit FSM: new state initial

Jan 6 21:07:00.311: CRYPTO_CS: cs config has been unlocked no sh

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

Jan 6 21:07:03.535: CRYPTO_CS: enter FSM: input state initial, input signal no shut

Re-enter password:

Jan 6 21:07:10.619: CRYPTO_CS: starting enabling checks

Jan 6 21:07:10.619: CRYPTO_CS: key 'sub' does not exist; generated automatically[OK]

Jan 6 21:07:20.535: %SSH-5-ENABLED: SSH 1.99 has been enabled

Jan 6 21:07:25.883: CRYPTO_CS: nvram filesystem

Jan 6 21:07:25.991: CRYPTO_CS: serial number 0x1 written.

Jan 6 21:07:27.863: CRYPTO_CS: created a new serial file.

Jan 6 21:07:27.863: CRYPTO_CS: authenticating the CA 'sub'

Jan 6 21:07:27.867: CRYPTO_PKI: Sending CA Certificate Request:

GET /cgi-bin/pkiclient.exe?operation=GetCACert&message=sub HTTP/1.0

User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI)

Jan 6 21:07:27.867: CRYPTO_PKI: can not resolve server name/IP address

Jan 6 21:07:27.871: CRYPTO_PKI: Using unresolved IP Address 192.0.2.6 Certificate has the

following attributes:

Fingerprint MD5: 328ACC02 52B25DB8 22F8F104 B6055B5B

Fingerprint SHA1: 02FD799D DD40C7A8 61DC53AB 1E89A3EA 2A729EE2

% Do you accept this certificate? [yes/no]:

Jan 6 21:07:30.879: CRYPTO_PKI: http connection opened

Jan 6 21:07:30.903: CRYPTO_PKI: HTTP response header:

HTTP/1.1 200 OK

Date: Thu, 06 Jan 2005 21:07:30 GMT

Server: server-IOS

Content-Type: application/x-x509-ca-cert

Configuring and Managing a Certificate Server for PKI Deployment

Examples

Expires: Thu, 06 Jan 2005 21:07:30 GMT

Last-Modified: Thu, 06 Jan 2005 21:07:30 GMT

Cache-Control: no-store, no-cache, must-revalidate

Pragma: no-cache

Accept-Ranges: none

Content-Type indicates we have received a CA certificate.

Jan 6 21:07:30.903: Received 507 bytes from server as CA certificate:

Jan 6 21:07:30.907: CRYPTO_PKI: transaction GetCACert completed

Jan 6 21:07:30.907: CRYPTO_PKI: CA certificate received.

Jan 6 21:07:30.927: CRYPTO_PKI: crypto_pki_authenticate_tp_cert()

Jan 6 21:07:30.927: CRYPTO_PKI: trustpoint sub authentication status = 0 y Trustpoint CA

certificate accepted.%

% Certificate request sent to Certificate Authority

% Enrollment in progress...

Router (cs-server)#

Jan 6 21:07:51.772: CRYPTO_CA: certificate not found

Jan 6 21:07:52.460: CRYPTO_CS: Publishing 213 bytes to crl file nvram:sub.crl

Jan 6 21:07:54.348: CRYPTO_CS: enrolling the server's trustpoint 'sub'

Jan 6 21:07:54.352: CRYPTO_CS: exit FSM: new state check failed

Jan 6 21:07:54.352: CRYPTO_CS: cs config has been locked

Jan 6 21:07:54.356: CRYPTO_PKI: transaction PKCSReq completed

Jan 6 21:07:54.356: CRYPTO_PKI: status:

Jan 6 21:07:55.016: CRYPTO_PKI: Certificate Request Fingerprint MD5: 1BA027DB 1C7860C7

EC188F65 64356C80

Jan 6 21:07:55.016: CRYPTO_PKI: Certificate Request Fingerprint SHA1: 840DB52C E17614CB

0C7BE187 0DFC884D D32CAA75

Jan 6 21:07:56.508: CRYPTO_PKI: can not resolve server name/IP address

Jan 6 21:07:56.508: CRYPTO_PKI: Using unresolved IP Address 192.0.2.6

Jan 6 21:07:56.516: CRYPTO_PKI: http connection opened

Jan 6 21:07:59.136: CRYPTO_PKI: received msg of 776 bytes

Jan 6 21:07:59.136: CRYPTO_PKI: HTTP response header:

HTTP/1.1 200 OK

Date: Thu, 06 Jan 2005 21:07:57 GMT

Server: server-IOS

Content-Type: application/x-pki-message

Expires: Thu, 06 Jan 2005 21:07:57 GMT

Last-Modified: Thu, 06 Jan 2005 21:07:57 GMT

Cache-Control: no-store, no-cache, must-revalidate

Pragma: no-cache

Accept-Ranges: none

Jan 6 21:07:59.324: The PKCS #7 message has 1 verified signers.

Jan 6 21:07:59.324: signing cert: issuer=cn=root1

Jan 6 21:07:59.324: Signed Attributes:

Jan 6 21:07:59.328: CRYPTO_PKI: status = 102: certificate request pending

Jan 6 21:08:00.788: CRYPTO_PKI: can not resolve server name/IP address

Jan 6 21:08:00.788: CRYPTO_PKI: Using unresolved IP Address 192.0.2.6

Jan 6 21:08:00.796: CRYPTO_PKI: http connection opened

Jan 6 21:08:11.804: CRYPTO_PKI: received msg of 776 bytes

Jan 6 21:08:11.804: CRYPTO_PKI: HTTP response header: HTTP/1.1 200 OK

Date: Thu, 06 Jan 2005 21:08:01 GMT

Server: server-IOS

Content-Type: application/x-pki-message

Expires: Thu, 06 Jan 2005 21:08:01 GMT

Last-Modified: Thu, 06 Jan 2005 21:08:01 GMT

Cache-Control: no-store, no-cache, must-revalidate

Pragma: no-cache

Accept-Ranges: none

Jan 6 21:08:11.992: The PKCS #7 message has 1 verified signers.

Jan 6 21:08:11.992: signing cert: issuer=cn=root1

Jan 6 21:08:11.996: Signed Attributes:

Jan 6 21:08:11.996: CRYPTO_PKI: status = 102: certificate request pending

Jan 6 21:08:21.996: CRYPTO_PKI: All sockets are closed for trustpoint sub.

Configuring and Managing a Certificate Server for PKI Deployment

Examples

Jan 6 21:08:31.996: CRYPTO_PKI: All sockets are closed for trustpoint sub.

Jan 6 21:08:41.996: CRYPTO_PKI: All sockets are closed for trustpoint sub.

Jan 6 21:08:51.996: CRYPTO_PKI: All sockets are closed for trustpoint sub.

Jan 6 21:09:01.996: CRYPTO_PKI: All sockets are closed for trustpoint sub.

Jan 6 21:09:11.996: CRYPTO_PKI: resend GetCertInitial, 1

Jan 6 21:09:11.996: CRYPTO_PKI: All sockets are closed for trustpoint sub.

Jan 6 21:09:11.996: CRYPTO_PKI: resend GetCertInitial for session: 0

Jan 6 21:09:11.996: CRYPTO_PKI: can not resolve server name/IP address

Jan 6 21:09:11.996: CRYPTO_PKI: Using unresolved IP Address 192.0.2.6

Jan 6 21:09:12.024: CRYPTO_PKI: http connection opened% Exporting Certificate Server signing

certificate and keys...

Jan 6 21:09:14.784: CRYPTO_PKI: received msg of 1611 bytes

Jan 6 21:09:14.784: CRYPTO_PKI: HTTP response header:

HTTP/1.1 200 OK

Date: Thu, 06 Jan 2005 21:09:13 GMT

Server: server-IOS

Content-Type: application/x-pki-message

Expires: Thu, 06 Jan 2005 21:09:13 GMT

Last-Modified: Thu, 06 Jan 2005 21:09:13 GMT

Cache-Control: no-store, no-cache, must-revalidate

Pragma: no-cache

Accept-Ranges: none

Jan 6 21:09:14.972: The PKCS #7 message has 1 verified signers.

Jan 6 21:09:14.972: signing cert: issuer=cn=root1

Jan 6 21:09:14.972: Signed Attributes:

Jan 6 21:09:14.976: CRYPTO_PKI: status = 100: certificate is granted

Jan 6 21:09:15.668: The PKCS #7 message contains 1 certs and 0 crls.

Jan 6 21:09:15.688: Newly-issued Router Cert: issuer=cn=root serial=2

Jan 6 21:09:15.688: start date: 21:08:03 GMT Jan 6 2005

Jan 6 21:09:15.688: end date: 21:08:03 GMT Jan 6 2006

Jan 6 21:09:15.688: Router date: 21:09:15 GMT Jan 6 2005

Jan 6 21:09:15.692: Received router cert from CA

Jan 6 21:09:15.740: CRYPTO_CA: certificate not found

Jan 6 21:09:15.744: CRYPTO_PKI: All enrollment requests completed for trustpoint sub.

Jan 6 21:09:15.744: %PKI-6-CERTRET: Certificate received from Certificate Authority

Jan 6 21:09:15.744: CRYPTO_PKI: All enrollment requests completed for trustpoint sub.

Jan 6 21:09:15.748: CRYPTO_CS: enter FSM: input state check failed, input signal cert

configured

Jan 6 21:09:15.748: CRYPTO_CS: starting enabling checks

Jan 6 21:09:15.748: CRYPTO_CS: nvram filesystem

Jan 6 21:09:15.796: CRYPTO_CS: found existing serial file.

Jan 6 21:09:15.820: CRYPTO_CS: old router cert flag 0x4

Jan 6 21:09:15.820: CRYPTO_CS: new router cert flag 0x44

Jan 6 21:09:18.432: CRYPTO_CS: DB version 1

Jan 6 21:09:18.432: CRYPTO_CS: last issued serial number is 0x1

Jan 6 21:09:18.480: CRYPTO_CS: CRL file sub.crl exists.

Jan 6 21:09:18.480: CRYPTO_CS: Read 213 bytes from crl file sub.crl.

Jan 6 21:09:18.532: CRYPTO_CS: SCEP server started

Jan 6 21:09:18.532: CRYPTO_CS: exit FSM: new state enabled

Jan 6 21:09:18.536: CRYPTO_CS: cs config has been locked

Jan 6 21:09:18.536: CRYPTO_PKI: All enrollment requests completed for trustpoint sub.

If the certiﬁcate server fails to enable or if the certiﬁcate server has trouble handling the request that has been

conﬁgured, you can use the debug crypto pki servercommand 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 certiﬁcate server can act as an RA for a 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.

Configuring and Managing a Certificate Server for PKI Deployment

Configuring a Certificate Server to Run in RA Mode

SUMMARY STEPS

1. enable

2. conﬁgure terminal

3. crypto pki trustpoint name

4. enrollment url url

5. subject-name x.500-name

6. exit

7. crypto pki server cs-label

8. mode ra [transparent]

9. auto-rollover [time-period]

10. grant auto rollover {ca-cert | ra-cert}

11. no shutdown

12. no shutdown

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Enters global conﬁguration mode.conﬁgure terminal

Example:

Step 2

Device# configure terminal

Declares the trustpoint that your RA mode certiﬁcate server

should use and enters ca-trustpoint conﬁguration mode.

crypto pki trustpoint name

Example:

Step 3

Device(config)# crypto pki trustpoint ra-server

Speciﬁes the enrollment URL of the issuing CA certiﬁcate

server (root certiﬁcate server).

enrollment url url

Example:

Step 4

Device(ca-trustpoint)# enrollment url

http://ca-server.company.com

Speciﬁes the subject name the RA uses.subject-name x.500-name

Step 5

Example:

Include “cn=ioscs RA” or “ou=ioscs RA” in

the subject name so that the issuing CA

certiﬁcate server can recognize the RA (see

Step 7 below).

Note

Device(ca-trustpoint)# subject-name cn=ioscs RA

Exits ca-trustpoint conﬁguration mode.exit

Example:

Step 6

Device(ca-trustpoint)# exit

Configuring and Managing a Certificate Server for PKI Deployment

Configuring a Certificate Server to Run in RA Mode

PurposeCommand or Action

Enables a certiﬁcate server and enters cs-server

conﬁguration mode.

crypto pki server cs-label

Example:

Step 7

The certiﬁcate servermust have the same name

as the trustpoint that was created in Step 3

above.

Note

Device(config)# crypto pki server ra-server

Places the PKI server into RA certiﬁcate server mode.mode ra [transparent]

Step 8

Example:

Use the transparent keyword to allow the CA server in

RA mode to interoperate with more than one type of CA

Device(cs-server)# mode ra

server. When the transparentkeyword is used, the original

PKCS#10 enrollment message is not re-signed and is

forwarded unchanged. This enrollment message makes

the IOS RA certiﬁcate server work with CA servers like

the Microsoft CA server.

(Optional) Enables the automatic CA certiﬁcate rollover

functionality.

auto-rollover [time-period]

Example:

Step 9

• time-period --default is 30 days.

Device(cs-server)# auto-rollover 90

(Optional) Automatically grants reenrollment requests for

subordinate CAs and RA-mode CAs without operator

intervention.

grant auto rollover {ca-cert | ra-cert}

Example:

Device(cs-server)# grant auto rollover ra-cert

Step 10

• ca-cert --Speciﬁes that the subordinate CA rollover

certiﬁcate is automatically granted.

• ra-cert --Speciﬁes that the RA-mode CA rollover

certiﬁcate is automatically granted.

If this is the ﬁrst time that a subordinate certiﬁcate server

is enabled and enrolled, the certiﬁcate request must be

manually granted.

Enables the certiﬁcate server.no shutdown

Step 11

Example:

After this command is issued, the RA

automatically enrolls with the root certiﬁcate

server. After the RA certiﬁcate has been

successfully received, you must issue the no

shutdown command again, which reenables

the certiﬁcate server.

Note

Device(cs-server)# no shutdown

Reenables the certiﬁcate server.no shutdown

Example:

Step 12

Device(cs-server)# no shutdown

Configuring and Managing a Certificate Server for PKI Deployment

Configuring a Certificate Server to Run in RA Mode

Configuring the Root Certificate Server to Delegate Enrollment Tasks to the RA Mode Certificate

Server

Perform the following steps on the router that is running the issuing certiﬁcate server; that is, conﬁgure the

root certiﬁcate server that is delegating enrollment tasks to the RA mode certiﬁcate server.

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 certiﬁcate requests”

of the command output for the crypto pki server info-requests command.

Note

SUMMARY STEPS

1. enable

2. crypto pki server cs-label info requests

3. crypto pki server cs-label grant req-id

4. conﬁgure terminal

5. crypto pki server cs-label

6. grant ra-auto

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Displays the outstanding RA certiﬁcate request.crypto pki server cs-label info requests

Step 2

Example:

This command is issued on the router that is

running the issuing certiﬁcate server.

Note

Device# crypto pki server root-server info requests

Grants the pending RA certiﬁcate request.crypto pki server cs-label grant req-id

Step 3

Example:

Because the issuing certiﬁcate server delegates

the enrollment request veriﬁcation task to the

RA, you must pay extra attention to the RA

certiﬁcate request before granting it.

Note

Device# crypto pki server root-server grant 9

Enters global conﬁguration mode.conﬁgure terminal

Example:

Step 4

Device# configure terminal

Enables a certiﬁcate server and enters cs-server

conﬁguration mode.

crypto pki server cs-label

Example:

Step 5

Device(config)# crypto pki server root-server

Configuring and Managing a Certificate Server for PKI Deployment

Configuring the Root Certificate Server to Delegate Enrollment Tasks to the RA Mode Certificate Server

PurposeCommand or Action

(Optional) Speciﬁes that all enrollment requests from an

RA are to be granted automatically.

grant ra-auto

Example:

Step 6

For the grant ra-auto command to work, you

have to include “cn=ioscs RA” or “ou=ioscs RA”

in the subject name of the RA certiﬁcate. (See

Step 2 above.)

Note

Device(cs-server)# grant ra-auto

What to Do Next

After you have conﬁgured a certiﬁcate server, you can use the preconﬁgured default values or specify values

through the CLI for the functionality of the certiﬁcate server. If you choose to specify values other than the

defaults, see the following section, “Conﬁguring Certiﬁcate Server Functionality .”

Configuring Certificate Server Functionality

After you have enabled a certiﬁcate server and are in certiﬁcate server conﬁguration mode, use any of the

steps in this task to conﬁgure basic certiﬁcate server functionality values other than the default values.

Certificate Server Default Values and Recommended Values

The default values for a certiﬁcate server are intended to address a relatively small network (of about ten

devices). For example, the database settings are minimal (through the database level minimalcommand) and

the certiﬁcate 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 the database level 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 ﬂexibility to store ﬁle types to different storage and publication locations.

SUMMARY STEPS

1. database url root-url

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

3. database url {cnm | crl | crt} publish root-url

4. database level {minimal | names | complete}

5. database username username [password [encr-type] password]

6. database archive {pkcs12 | pem}[password encr-type] password ]

7. issuer-name DN-string

8. lifetime {ca-certiﬁcate | certiﬁcate} time

9. lifetime crl time

10. lifetime enrollment-request time

11. cdp-url url

12. no shutdown

Configuring and Managing a Certificate Server for PKI Deployment

What to Do Next

DETAILED STEPS

PurposeCommand or Action

Speciﬁes the primary location where database entries for

the certiﬁcate server are written.

database url root-url

Example:

Step 1

If this command is not speciﬁed, all database entries are

written to NVRAM.

Device(cs-server)# database url

tftp://cert-svr-db.company.com

Speciﬁes certiﬁcate server critical ﬁle storage location by

ﬁle type.

database url {cnm | crl | crt | p12 | pem | ser} root-url

Example:

Step 2

If this command is not speciﬁed, all critical ﬁles

are stored to the primary location if speciﬁed.

If the primary location is not speciﬁed, all

critical ﬁles are stored to NVRAM.

Note

Device(cs-server)# database url ser nvram:

Speciﬁes certiﬁcate server publish location by ﬁle type.database url {cnm | crl | crt} publish root-url

Step 3

Example:

If this command is not speciﬁed, all publish

ﬁles are stored to the primary location if

speciﬁed. If the primary location is not

speciﬁed, all publish ﬁles are stored to

NVRAM.

Note

Device(cs-server)# database url crl publish

tftp://csdb_specific_crl_files.company.com

Controls what type of data is stored in the certiﬁcate

enrollment database.

database level {minimal | names | complete}

Example:

Step 4

• minimal --Enough information is stored only to

continue issuing new certiﬁcates without conﬂict; the

default value.

Device(cs-server)# database level complete

• names --In addition to the information given in the

minimal level, the serial number and subject name of

each certiﬁcate.

• complete --In addition to the information given in

the minimal and names levels, each issued certiﬁcate

is written to the database.

The complete keywordproduces 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 database url

command.

Note

(Optional) Sets a username and password when a user is

required to access a primary certiﬁcate enrollment database

storage location.

database username username [password [encr-type]

password]

Example:

Step 5

Device(cs-server)# database username user password

PASSWORD

Configuring and Managing a Certificate Server for PKI Deployment

Certificate Server File Storage and Publication Locations

PurposeCommand or Action

(Optional) Sets the CA key and CA certiﬁcate archive

format and password to encrypt the ﬁle.

database archive {pkcs12 | pem}[password encr-type]

password ]

Step 6

Example:

The default value is pkcs12, so if this subcommand is not

conﬁgured, autoarchiving continues, and the PKCS12

format is used.

Device(cs-server)# database archive pem

• The password is optional. If it is not conﬁgured, you

are prompted for the password when the server is

turned on for the ﬁrst time.

It is recommended that you remove the

password from the conﬁguration after the

archive is ﬁnished.

Note

(Optional) Sets the CA issuer name to the speciﬁed

distinguished name (DN-string). The default value is as

follows: issuer-name cn={cs-label }.

issuer-name DN-string

Example:

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

Step 7

(Optional) Speciﬁes the lifetime, in days, of a CA

certiﬁcate or a certiﬁcate.

lifetime {ca-certiﬁcate | certiﬁcate} time

Example:

Step 8

Valid values range from 1 day to 1825 days. The default

CA certiﬁcate lifetime is 3 years; the default certiﬁcate

Device(cs-server)# lifetime certificate 888

lifetime is 1 year. The maximum certiﬁcate lifetime is 1

month less than the lifetime of the CA certiﬁcate.

(Optional) Deﬁnes the lifetime, in hours, of the CRL that

is used by the certiﬁcate server.

lifetime crl time

Example:

Step 9

Maximum lifetime value is 336 hours (2 weeks). The

default value is 168 hours (1 week).

Device(cs-server)# lifetime crl 333

(Optional) Speciﬁes how long an enrollment request should

stay in the enrollment database before being removed.

lifetime enrollment-request time

Example:

Step 10

Maximum lifetime is 1000 hours.

Device(cs-server)# lifetime enrollment-request

888

(Optional) Deﬁnes the CDP location to be used in the

certiﬁcates that are issued by the certiﬁcate server.

cdp-url url

Example:

Step 11

• The URL must be an HTTP URL.

Device(cs-server)# cdp-url

http://my-cdp.company.com

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/ﬁlename.crl

Or, if your Cisco IOS certiﬁcate server is also conﬁgured

as your CDP, use the following URL format

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

Configuring and Managing a Certificate Server for PKI Deployment

Certificate Server File Storage and Publication Locations

PurposeCommand or Action

where cs-addr is the location of the certiﬁcate server.

In order to force the parser to retain the embedded question

mark within the speciﬁed location, enter Ctrl-v prior to

the question mark. If this action is not taken, CRL retrieval

through HTTP returns an error message.

Although this command is optional, it is

strongly recommended for any deployment

scenario.

Note

Enables the certiﬁcate server.no shutdown

Step 12

Example:

You should issue this command only after you have

completely conﬁgured your certiﬁcate server.

Device(cs-server)# no shutdown

Examples

The following example shows how to conﬁgure a CDP location where the PKI clients do not support

SCEP GetCRL requests:

Device(config)# crypto pki server aaa

Device(cs-server)# database level minimum

Device(cs-server)# database url tftp://10.1.1.1/username1/

Device(cs-server)# issuer-name CN=aaa

Device(cs-server)# cdp-url http://server.company.com/certEnroll/aaa.crl

After a certiﬁcate server has been enabled on a router, the show crypto pki servercommand displays

the following output:

Device# show crypto pki server

Certificate Server status:enabled, configured

Granting mode is:manual

Last certificate issued serial number:0x1

CA certificate expiration timer:19:31:15 PST Nov 17 2006

CRL NextUpdate timer:19:31:15 PST Nov 25 2003

Current storage dir:nvram:

Database Level:Minimum - no cert data written to storage

Working with Automatic CA Certificate Rollover

Starting Automated CA Certificate Rollover Immediately

Use this task to initiate the automated CA certiﬁcate rollover process immediately on your root CA server.

SUMMARY STEPS

1. enable

2. conﬁgure terminal

3. crypto pki server cs-label rollover [cancel]

Configuring and Managing a Certificate Server for PKI Deployment

Working with Automatic CA Certificate Rollover

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Enters global conﬁguration mode.conﬁgure terminal

Example:

Step 2

Device# configure terminal

Immediately starts the CA certiﬁcate rollover process by

generating a shadow CA certiﬁcate.

crypto pki server cs-label rollover [cancel]

Example:

Step 3

To delete the CA certiﬁcate rollover certiﬁcate and keys,

use the cancel keyword.

Device(config)# crypto pki server mycs rollover

Requesting a Certificate Server Client Rollover Certificate

Use this task to request a certiﬁcate server client’s rollover certiﬁcate.

SUMMARY STEPS

1. enable

2. conﬁgure terminal

3. crypto pki server cs-label rollover request pkcs10 terminal

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Enters global conﬁguration mode.conﬁgure terminal

Example:

Step 2

Device# configure terminal

Requests a client rollover certiﬁcate from the server.crypto pki server cs-label rollover request pkcs10

terminal

Step 3

Example:

Device(config)# crypto pki server mycs rollover

request pkcs10 terminal

Example

The following example shows a rollover certiﬁcate request being inputted into the server:

Configuring and Managing a Certificate Server for PKI Deployment

Requesting a Certificate Server Client Rollover Certificate

Device# crypto pki server mycs rollover request pkcs10 terminal

% Enter Base64 encoded or PEM formatted PKCS10 enrollment request.

% End with a blank line or "quit" on a line by itself.

-----BEGIN CERTIFICATE REQUEST-----

MIIBUTCBuwIBADASMRAwDgYDVQQDEwdOZXdSb290MIGfMA0GCSqGSIb3DQEBAQUA

A4GNADCBiQKBgQDMHeev1ERSs320zbLQQk+3lhV/R2HpYQ/iM6uT1jkJf5iy0UPR

wF/X16yUNmG+ObiGiW9fsASF0nxZw+fO7d2X2yh1PakfvF2wbP27C/sgJNOw9uPf

sBxEc40Xe0d5FMh0YKOSAShfZYKOflnyQR2Drmm2x/33QGol5QyRvjkeWQIDAQAB

oAAwDQYJKoZIhvcNAQEEBQADgYEALM90r4d79X6vxhD0qjuYJXfBCOvv4FNyFsjr

aBS/y6CnNVYySF8UBUohXYIGTWf4I4+sj6i8gYfoFUW1/L82djS18TLrUr6wpCOs

RqfAfps7HW1e4cizOfjAUU+C7lNcobCAhwF1o6q2nIEjpQ/2yfK9O7sb3SCJZBfe

eW3tyCo=

-----END CERTIFICATE REQUEST-----

Exporting a CA Rollover Certificate

Use this task to export a CA rollover certiﬁcate.

SUMMARY STEPS

1. enable

2. conﬁgure terminal

3. crypto pki export trustpoint pem {terminal | url url} [rollover]

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Enters global conﬁguration mode.conﬁgure terminal

Example:

Step 2

Device# configure terminal

Exports a CA shadow certiﬁcate.crypto pki export trustpoint pem {terminal | url url}

[rollover]

Step 3

Example:

Device(config)# crypto pki export mycs pem terminal

rollover

Maintaining Verifying and Troubleshooting the Certificate Server Certificates

and the CA

Managing the Enrollment Request Database

SCEP supports two client authentication mechanisms--manual and preshared key. Manual enrollment requires

the administrator at the CA server to speciﬁcally authorize the enrollment requests; enrollment using preshared

keys allows the administrator to preauthorize enrollment requests by generating a one-time password (OTP).

Configuring and Managing a Certificate Server for PKI Deployment

Exporting a CA Rollover Certificate

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 certiﬁcate server.

SUMMARY STEPS

1. enable

2. crypto pki server cs-label grant {all | req-id}

3. crypto pki server cs-label reject {all | req-id}

4. crypto pki server cs-label password generate minutes

5. crypto pki server cs-label revoke certiﬁcate-serial-number

6. crypto pki server cs-label request pkcs10 {url | terminal} [base64| pem

7. show crypto pki server cs-label crl

8. show crypto pki server cs-label requests

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Grants all or speciﬁc SCEP requests.crypto pki server cs-label grant {all | req-id}

Example:

Step 2

Device# crypto pki server mycs grant all

Rejects all or speciﬁc SCEP requests.crypto pki server cs-label reject {all | req-id}

Example:

Step 3

Device# crypto pki server mycs reject all

Generates a OTP for SCEP requests.crypto pki server cs-label password generate minutes

Step 4

Example:

• minutes --Length of time, in minutes, that the password

is valid. Valid values range from 1 to 1440 minutes.

The default is 60 minutes.

Device# crypto pki server mycs password generate

Only one OTP is valid at a time; if a second OTP

is generated, the previous OTP is no longer valid.

Note

Revokes a certiﬁcate on the basis of its serial number.crypto pki server cs-label revoke

certiﬁcate-serial-number

Step 5

• certiﬁcate-serial-number --One of the following

options:

Example:

Device# crypto pki server mycs revoke 3

• 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

Configuring and Managing a Certificate Server for PKI Deployment

Managing the Enrollment Request Database

PurposeCommand or Action

Manually adds either a base64-encoded or PEM-formatted

PKCS10 certiﬁcate enrollment request to the request

database.

crypto pki server cs-label request pkcs10 {url |

terminal} [base64| pem

Example:

Step 6

After the certiﬁcate is granted, it is displayed on the console

terminal using base64 encoding.

Device# crypto pki server mycs request pkcs10

terminal pem

• pem --Speciﬁes the certiﬁcate that is returned with

PEM headers automatically added to the certiﬁcate

after the certiﬁcate is granted, regardless of whether

PEM headers were used in the request.

• base64 --Speciﬁes the certiﬁcate that is returned

without privacy-enhanced mail (PEM) headers,

regardless of whether PEM headers were used in the

request.

Displays information regarding the status of the current

CRL.

show crypto pki server cs-label crl

Example:

Step 7

Device# show crypto pki server mycs crl

Displays all outstanding certiﬁcate enrollment requests.

show crypto pki server cs-label requests

Example:

Step 8

Device# show crypto pki server mycs requests

Removing Requests from the Enrollment Request Database

After the certiﬁcate 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

certiﬁcate server for the result of the request. If the client exits and never polls the certiﬁcate 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. crypto pki server cs-label remove {all | req-id}

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Configuring and Managing a Certificate Server for PKI Deployment

Removing Requests from the Enrollment Request Database

PurposeCommand or Action

Removes enrollment requests from the enrollment request

database.

crypto pki server cs-label remove {all | req-id}

Example:

Step 2

Device# crypto pki server mycs remove 15

Deleting a Certificate Server

Users can delete a certiﬁcate server from the PKI conﬁguration if they no longer want it on the conﬁguration.

Typically, a subordinate certiﬁcate server or an RA is being deleted. However, users may delete a root

certiﬁcate server if they are moving it to another device through the archived RSA keys.

Perform this task to delete a certiﬁcate server from your PKI conﬁguration.

When a certiﬁcate server is deleted, the associated trustpoint and key are also deleted.

Note

SUMMARY STEPS

1. enable

2. conﬁgure terminal

3. no crypto pki server cs-label

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Enters global conﬁguration mode.conﬁgure terminal

Example:

Step 2

Device# configure terminal

Deletes a certiﬁcate server and associated trustpoint and

key.

no crypto pki server cs-label

Example:

Step 3

Device(config)# no crypto pki server mycs

Verifying and Troubleshooting Certificate Server and CA Status

Use any of the following optional steps to verify the status of the certiﬁcate server or the CA.

SUMMARY STEPS

1. enable

2. debug crypto pki server

3. dir ﬁlesystem :

Configuring and Managing a Certificate Server for PKI Deployment

Deleting a Certificate Server

DETAILED STEPS

PurposeCommand or Action

Enables privileged EXEC mode.enable

Step 1

Example:

• Enter your password if prompted.

Device> enable

Enables debugging for a crypto PKI certiﬁcate server.debug crypto pki server

Step 2

Example:

• This command can be used for monitoring the progress

of an enrollment and for troubleshooting if the

Device# debug crypto pki server

certiﬁcate server fails to respond or if the certiﬁcate

server has trouble handling the request that has been

conﬁgured.

Displays a list of ﬁles on a ﬁle system.dir ﬁlesystem :

Step 3

Example:

• This command can be used to verify the certiﬁcate

server autoarchived ﬁle if the database url command

Device# dir slot0:

was entered to point to a local ﬁle system. You should

be able to at least see “cs-label .ser” and “cs-label .crl”

ﬁles in the database.

Verifying CA Certificate Information

To obtain information relating to the CA certiﬁcates including the certiﬁcate server rollover process, rollover

certiﬁcates, and timers, you may use any of the following commands.

These commands are not exclusive to shadow certiﬁcate information. If no shadow certiﬁcate exists, the

following commands display the active certiﬁcate information.

Note

SUMMARY STEPS

1. crypto pki certiﬁcate chain

2. crypto pki server info requests

3. show crypto pki certiﬁcates

4. show crypto pki server

5. show crypto pki trustpoints

DETAILED STEPS

Step 1 crypto pki certiﬁcate chain

Example:

Device(config)# crypto pki certificate chain mica

certificate 06

Configuring and Managing a Certificate Server for PKI Deployment

Verifying CA Certificate Information

certificate ca 01

! This is the peer’s shadow PKI certificate.

certificate rollover 0B

! This is the CA shadow PKI certificate

certificate rollover ca 0A

Displays the certiﬁcate chain details and to distinguish the current active certiﬁcate from the rollover certiﬁcate in the

certiﬁcate chain. The following example shows a certiﬁcate chain with an active CA certiﬁcate and a shadow, or rollover,

certiﬁcate:

Step 2 crypto pki server info requests

Example:

Device# crypto pki server myca info requests

Enrollment Request Database:

RA certificate requests:

ReqID State Fingerprint SubjectName

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

RA rollover certificate requests:

ReqID State Fingerprint SubjectName

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

Router certificates requests:

ReqID State Fingerprint SubjectName

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

1 pending A426AF07FE3A4BB69062E0E47198E5BF hostname=client

Router rollover certificates requests:

ReqID State Fingerprint SubjectName

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

2 pending B69062E0E47198E5BFA426AF07FE3A4B hostname=client

Displays all outstanding certiﬁcate enrollment requests. The following example shows the output for shadow PKI certiﬁcate

information requests:

Step 3 show crypto pki certiﬁcates

Example:

Device# show crypto pki certificates

Certificate

Subject Name

Name: myrouter.example.com

IP Address: 192.0.2.1

Serial Number: 04806682

Status: Pending

Key Usage: General Purpose

Fingerprint: 428125BD A3419600 3F6C7831 6CD8FA95 00000000

CA Certificate

Status: Available

Certificate Serial Number: 3051DF7123BEE31B8341DFE4B3A338E5F

Key Usage: Not Set

Displays information about the certiﬁcate, the certiﬁcation authority certiﬁcate, shadow certiﬁcates, and any registration

authority certiﬁcates. The following example displays the certiﬁcate of the router and the certiﬁcate of the CA. There is

no shadow certiﬁcate available. A single, general-purpose RSA key pair was previously generated, and a certiﬁcate was

requested but not received for that key pair. Note that the certiﬁcate status of the router shows “Pending.” After the router

receives its certiﬁcate from the CA, the Status ﬁeld changes to “Available” in the show output.

Step 4 show crypto pki server

Example:

Configuring and Managing a Certificate Server for PKI Deployment

Verifying CA Certificate Information

Device# show crypto pki server

Certificate Server routercs:

Status: enabled, configured

Issuer name: CN=walnutcs

CA cert fingerprint: 800F5944 74337E5B C2DF6C52 9A7B1BDB

Granting mode is: auto

Last certificate issued serial number: 0x7

CA certificate expiration timer: 22:10:29 GMT Jan 29 2007

CRL NextUpdate timer: 21:50:56 GMT Mar 5 2004

Current storage dir: nvram:

Database Level: Minimum - no cert data written to storage

Rollover status: available for rollover

Rollover CA cert fingerprint: 6AAF5944 74227A5B 23DF3E52 9A7F1FEF

Rollover CA certificate expiration timer: 22:10:29 GMT Jan 29 2017

Displays the current state and conﬁguration of the certiﬁcate server. The following example shows that the certiﬁcate

server “routercs” has rollover conﬁgured. The CA auto-rollover time has occurred and the rollover, or shadow, PKI

certiﬁcate is available. The status shows the rollover certiﬁcate ﬁngerprint and rollover CA certiﬁcate expiration timer

information.

Step 5 show crypto pki trustpoints

Example:

Device# show crypto pki trustpoints

Trustpoint vpn:

Subject Name:

cn=Cisco SSL CA

o=Cisco Systems

Serial Number: 0FFEBBDC1B6F6D9D0EA7875875E4C695

Certificate configured.

Rollover certificate configured.

Enrollment Protocol:

SCEPv1, PKI Rollover

Displays the trustpoints that are conﬁgured in the device. The following output shows that a shadow CA certiﬁcate is

available and shows the SCEP capabilities reported during the last enrollment operation:

Configuration Examples for Using a Certificate Server

Example: Configuring Specific Storage and Publication Locations

The following example shows the conﬁguration of a minimal local ﬁle system, so that the certiﬁcate server

can respond quickly to certiﬁcate requests. The .ser and .crl ﬁles are stored on the local system for fast access,

and a copy of all of the .crt ﬁles are published to a remote location for long-term logging.

crypto pki server myserver

!Pick your database level.

database level minimum

!Specify a location for the .crt files that is different than the default local

!Cisco IOS file system.

database url crt publish http://url username user1 password secret

Configuring and Managing a Certificate Server for PKI Deployment

Configuration Examples for Using a Certificate Server

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

Note

The following example shows the conﬁguration of a primary storage location for critical ﬁles, a speciﬁc

storage location for the critical ﬁle serial number ﬁle, the main certiﬁcate server database ﬁle, and a password

protected ﬁle publication location for the CRL ﬁle:

Device(config)# crypto pki server mycs

Device(cs-server)# database url ftp://cs-db.company.com

% Server database url was changed. You need to move the

% existing database to the new location.

Device(cs-server)# database url ser nvram:

Device(cs-server)# database url crl publish ftp://crl.company.com username myname password

mypassword

Device(cs-server)# end

The following output displays the speciﬁed primary storage location and critical ﬁle storage locations speciﬁed:

Device# show

Sep 3 20:19:34.216: %SYS-5-CONFIG_I: Configured from console by user on console

Device# show crypto pki server

Certificate Server mycs:

Status: disabled

Server's configuration is unlocked (enter "no shut" to lock it)

Issuer name: CN=mycs

CA cert fingerprint: -Not found-

Granting mode is: manual

Last certificate issued serial number: 0x0

CA certificate expiration timer: 00:00:00 GMT Jan 1 1970

CRL not present.

Current primary storage dir: ftp://cs-db.company.com

Current storage dir for .ser files: nvram:

Database Level: Minimum - no cert data written to storage The following output displays

all storage and publication locations. The serial number file (.ser) is stored in NVRAM.

The CRL file will be published to ftp://crl.company.com with a username and password. All

other critical files will be stored to the primary location, ftp://cs-db.company.com.

Device# show running-config

section crypto pki server

crypto pki server mycs shutdown database url ftp://cs-db.company.com

database url crl publish ftp://crl.company.com username myname password 7

12141C0713181F13253920

database url ser nvram:

Device#

Example:RemovingEnrollmentRequestsfromtheEnrollmentRequestDatabase

The following examples show both the enrollment requests that are currently in the enrollment request database

and the result after one of the enrollment requests has been removed from the database.

Configuring and Managing a Certificate Server for PKI Deployment

Example: Removing Enrollment Requests from the Enrollment Request Database

Example: Enrollment Request Currently in the Enrollment Request Database

The following example shows that the crypto pki server info requests command has been used to display

the enrollment requests that are currently in the Enrollment Request Database:

Device# crypto pki server myserver info requests

Enrollment Request Database:

RA certificate requests:

ReqID State Fingerprint SubjectName

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

Router certificates requests:

ReqID State Fingerprint SubjectName

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

2 pending 1B07F3021DAAB0F19F35DA25D01D8567 hostname=host1.company.com

1 denied 5322459D2DC70B3F8EF3D03A795CF636 hostname=host2.company.com

Example: crypto pki server remove Command Used to Remove One Enrollment Request

The following example shows that the crypto pki server removecommand has been used to remove Enrollment

Request 1:

Device# crypto pki server myserver remove 1

Example: Enrollment Request Database After the Removal of One Enrollment Request

The following example shows the result of the removal of Enrollment Request 1 from the Enrollment Request

Database:

Device# crypto pki server mycs info requests

Enrollment Request Database:

RA certificate requests:

ReqID State Fingerprint SubjectName

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

Router certificates requests:

ReqID State Fingerprint SubjectName

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

2 pending 1B07F3021DAAB0F19F35DA25D01D8567 hostname=host1.company.com

Example: Autoarchiving the Certificate Server Root Keys

The following output conﬁgurations and examples show what you might see if the database archive command

has not been conﬁgured (that is, conﬁgured using the default value); if the database archive command has

been conﬁgured to set the CA certiﬁcate and CA key archive format as PEM, without conﬁguring a password;

and if the database archive command has been conﬁgured to set the CA certiﬁcate and CA key archive

format as PKCS12, with a password conﬁgured. The last example is sample content of a PEM-formatted

archive ﬁle. The following example, “ms2” refers to the label of a 2048-bit key pair.

Example: database archive Command Not Configured

The default is PKCS12, and the prompt for the password appears after the no shutdown command has been

issued.

Note

Configuring and Managing a Certificate Server for PKI Deployment

Example: Autoarchiving the Certificate Server Root Keys

Device(config)# crypto pki server ms2

Device(cs-server)# no shutdown

% Ready to generate the CA certificate.

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

Are you sure you want to do this? [yes/no]: y

% Exporting Certificate Server signing certificate and keys...

! Note the next two lines, which are asking for a password.

% Please enter a passphrase to protect the private key.

Password:

% Certificate Server enabled.

Device(cs-server)# end

Device# dir nvram:

Directory of nvram:/

125 -rw- 1693 <no date> startup-config

126 ---- 5 <no date> private-config

1 -rw- 32 <no date> myserver.ser

2 -rw- 214 <no date> myserver.crl

! Note the next line, which indicates PKCS12 format.

3 -rw- 1499 <no date> myserver.p12

Example" database archive Command and pem Keyword Configured

The prompt for the password appears after the no shutdown command has been issued.

Note

Device(config)# crypto pki server ms2

Device(cs-server)# database archive pem

Device(cs-server)# no shutdown

% Ready to generate the CA certificate.

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

Are you sure you want to do this? [yes/no]: y

% Exporting Certificate Server signing certificate and keys...

!Note the next two lines, which are asking for a password.

% Please enter a passphrase to protect the private key.

Password:

% Certificate Server enabled.

Device(cs-server)# end

Device# dir nvram

Directory of nvram:/

125 -rw- 1693 <no date> startup-config

126 ---- 5 <no date> private-config

1 -rw- 32 <no date> myserver.ser

2 -rw- 214 <no date> myserver.crl

! Note the next line showing that the format is PEM.

3 -rw- 1705 <no date> myserver.pem

Example: database archive Command and pkcs12 Keyword (and Password) Configured

When the password is entered, it is encrypted. However, it is recommended that you remove the password

from the conﬁguration after the archive has ﬁnished.

Note

Configuring and Managing a Certificate Server for PKI Deployment

Example: Autoarchiving the Certificate Server Root Keys

Device(config)# crypto pki server ms2

Device(cs-server)# database archive pkcs12 password cisco123

Device(cs-server)# no shutdown

% Ready to generate the CA certificate.

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

Are you sure you want to do this? [yes/no]: y

% Exporting Certificate Server signing certificate and keys...

! Note that you are not being prompted for a password.

% Certificate Server enabled.

Device(cs-server)# end

Device# dir nvram:

Directory of nvram:/

125 -rw- 1693 <no date> startup-config

126 ---- 5 <no date> private-config

1 -rw- 32 <no date> myserver.ser

2 -rw- 214 <no date> myserver.crl

! Note that the next line indicates that the format is PKCS12.

3 -rw- 1499 <no date> myserver.p12

Example: PEM-Formatted Archive

The following sample output shows that autoarchiving has been conﬁgured in PEM ﬁle format. The archive

consists of the CA certiﬁcate and the CA private key. To restore the certiﬁcate server using the backup, you

would have to import the PEM-formatted CA certiﬁcate and CA key individually.

In addition to the CA certiﬁcate and CA key archive ﬁles, you should also back up the serial ﬁle (.ser) and

the CRL ﬁle (.crl) regularly. The serial ﬁle and the CRL ﬁle are both critical for CA operation if you need to

restore your certiﬁcate server.

Note

Device# more nvram:mycs.pem

-----BEGIN CERTIFICATE-----

MIIB9zCCAWCgAwIBAgIBATANBgkqhkiG9w0BAQQFADAPMQ0wCwYDVQQDEwRteWNz

MB4XDTA0MDgyNzAyMzI0NloXDTA3MDgyNzAyMzI0NlowDzENMAsGA1UEAxMEbXlj

czCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1lZpKP4nGDJHgPkpYSkix7lD

nr23aMlZ9Kz5oo/qTBxeZ8mujpjYcZ0T8AZvoOiCuDnYMl796ZwpkMgjz1aZZbL+

BtuVvllsEOfhC+u/Ol/vxfGG5xpshoz/F5J3xdg5ZZuWWuIDAUYu9+QbI5feuG04

Z/BiPIb4AmGTP4B2MM0CAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8B

Af8EBAMCAYYwHwYDVR0jBBgwFoAUKi/cuK6wkz+ZswVtb06vUJboEeEwHQYDVR0O

BBYEFCov3LiusJM/mbMFbW9Or1CW6BHhMA0GCSqGSIb3DQEBBAUAA4GBAKLOmoE2

4+NeOKEXMCXG1jcohK7O2HrkFfl/vpK0+q92PTnMUFhxLOqI8pWIq5CCgC7heace

OrTv2zcUAoH4rzx3Rc2USIxkDokWWQMLujsMm/SLIeHit0G5uj//GCcbgK20MAW6

ymf7+TmblSFljWzstoUXC2hLnsJIMq/KffaD

-----END CERTIFICATE-----

!The private key is protected by the password that is

configured in “database archive pem password pwd” or that

is entered when you are prompted for the password.

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,106CE91FFD0A075E

zyiFC8rKv8Cs+IKsQG2QpsVpvDBHqZqBSM4D528bvZv7jzr6WuHj8E6zO+6G8R/A

zjsfTALo+e+ZDg7KMzbryHARvjskbqFdOMLlVIYBhCeSElKsskWB6chOuyPHJInW

JwC5YzZdZwOqcyLBP/xOYXcvjzzNfPAXZzN12VR8vWDNq/kHT+3Lplc8hY++ABMI

M+C9FB3dpNZzu5O1BZCJg46bqbkulaCCmScIDaVt0zDFZwWTSufiemmNxZBG4xS8

Configuring and Managing a Certificate Server for PKI Deployment

Example: Autoarchiving the Certificate Server Root Keys

t5t+FEhmSfv8DAmwg4f/KVRFTm10phUArcLxQO38Al0W5YHHORdACnuzVUvHgco7

VT4XUTjO7qMhmJgFNWy1pu49fbdS2NnOn5IoiyAq5lk1KUPrz/WABWiCvLMylGnZ

kyMCWoaMtgS/vdx74BBCj09yRZJnLMlIi6SDofjCNTDHfmFEVg4LsSWCd4lP9OP8

0MqhP1D5VIx6PbMNwkWW12lpBbCCdesFRGHjZD2dOu96kHD7ItErx34CC8W04aG4

b7DLktUu6WNV6M8g3CAqJiC0V8ATlp+kvdHZVkXovgND5IU0OJpsj0HhGzKAGpOY

KTGTUekUboISjVVkI6efp1vO6temVL3Txg3KGhzWMJGrq1snghE0KnV8tkddv/9N

d/t1l+we9mrccTq50WNDnkEi/cwHI/0PKXg+NDNH3k3QGpAprsqGQmMPdqc5ut0P

86i4cF9078QwWg4Tpay3uqNH1Zz6UN0tcarVVNmDupFESUxYw10qJrrEYVRadu74

rKAU4Ey4xkAftB2kuqvr21Av/L+jne4kkGIoZYdB+p/M98pQRgkYyg==

-----END RSA PRIVATE KEY-----

Example: Restoring a Certificate Server from Certificate Server Backup Files

The following example shows that restoration is from a PKCS12 archive and that the database URL is NVRAM

(the default).

Device# copy tftp://192.0.2.71/backup.ser nvram:mycs.ser

Destination filename [mycs.ser]?

32 bytes copied in 1.320 secs (24 bytes/sec)

Device# copy tftp://192.0.2.71/backup.crl nvram:mycs.crl

Destination filename [mycs.crl]?

214 bytes copied in 1.324 secs (162 bytes/sec)

Device# configure terminal

Device(config)# crypto pki import mycs pkcs12 tftp://192.0.2.71/backup.p12 cisco123

Source filename [backup.p12]?

CRYPTO_PKI: Imported PKCS12 file successfully.

Device(config)# crypto pki server mycs

! fill in any certificate server configuration here

Device(cs-server)# no shutdown

% Certificate Server enabled.

Device(cs-server)# end

Device# show crypto pki server

Certificate Server mycs:

Status: enabled

Server's current state: enabled

Issuer name: CN=mycs

CA cert fingerprint: 34885330 B13EAD45 196DA461 B43E813F

Granting mode is: manual

Last certificate issued serial number: 0x1

CA certificate expiration timer: 01:49:13 GMT Aug 28 2007

CRL NextUpdate timer: 01:49:16 GMT Sep 4 2004

Current storage dir: nvram:

Database Level: Minimum - no cert data written to storage

The following example shows that restoration is from a PEM archive and that the database URL is ﬂash:

Device# copy tftp://192.0.2.71/backup.ser flash:mycs.ser

Destination filename [mycs.ser]?

32 bytes copied in 1.320 secs (24 bytes/sec)

Router# copy tftp://192.0.2.71/backup.crl flash:mycs.crl

Destination filename [mycs.crl]?

Configuring and Managing a Certificate Server for PKI Deployment

Example: Restoring a Certificate Server from Certificate Server Backup Files

214 bytes copied in 1.324 secs (162 bytes/sec)

Device# configure terminal

! Because CA cert has Digital Signature usage, you need to import using the "usage-keys"

keyword

Device(config)# crypto ca import mycs pem usage-keys terminal cisco123

% Enter PEM-formatted CA certificate.

% End with a blank line or "quit" on a line by itself.

! Paste the CA cert from .pem archive.

-----BEGIN CERTIFICATE-----

MIIB9zCCAWCgAwIBAgIBATANBgkqhkiG9w0BAQQFADAPMQ0wCwYDVQQDEwRteWNz

MB4XDTA0MDkwMjIxMDI1NloXDTA3MDkwMjIxMDI1NlowDzENMAsGA1UEAxMEbXlj

czCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuGnnDXJbpDDQwCuKGs5Zg2rc

K7ZJauSUotTmWYQvNx+ZmWrUs5/j9Ee5FV2YonirGBQ9mc6u163kNlrIPFck062L

GpahBhNmKDgod1o2PHTnRlZpEZNDIqU2D3hACgByxPjrY4vUnccV36ewLnQnYpp8

szEu7PYTJr5dU5ltAekCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8B

Af8EBAMCAYYwHwYDVR0jBBgwFoAUaEEQwYKCQ1dm9+wLYBKRTlzxaDIwHQYDVR0O

BBYEFGhBEMGCgkNXZvfsC2ASkU5c8WgyMA0GCSqGSIb3DQEBBAUAA4GBAHyhiv2C

mH+vswkBjRA1Fzzk8ttu9s5kwqG0dXp25QRUWsGlr9nsKPNdVKt3P7p0A/KochHe

eNiygiv+hDQ3FVnzsNv983le6O5jvAPxc17RO1BbfNhqvEWMsXdnjHOcUy7XerCo

+bdPcUf/eCiZueH/BEy/SZhD7yovzn2cdzBN

-----END CERTIFICATE-----

% Enter PEM-formatted encrypted private SIGNATURE key.

% End with "quit" on a line by itself.

! Paste the CA private key from .pem archive.

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,5053DC842B04612A

1CnlF5Pqvd0zp2NLZ7iosxzTy6nDeXPpNyJpxB5q+V29IuY8Apb6TlJCU7YrsEB/

nBTK7K76DCeGPlLpcuyEI171QmkQJ2gA0QhC0LrRo09WrINVH+b4So/y7nffZkVb

p2yDpZwqoJ8cmRH94Tie0YmzBtEh6ayOud11z53qbrsCnfSEwszt1xrW1MKrFZrk

/fTy6loHzGFzl3BDj4r5gBecExwcPp74ldHO+Ld4Nc9egG8BYkeBCsZZOQNVhXLN

I0tODOs6hP915zb6OrZFYv0NK6grTBO9D8hjNZ3U79jJzsSP7UNzIYHNTzRJiAyu

i56Oy/iHvkCSNUIK6zeIJQnW4bSoM1BqrbVPwHU6QaXUqlNzZ8SDtw7ZRZ/rHuiD

RTJMPbKquAzeuBss1132OaAUJRStjPXgyZTUbc+cWb6zATNws2yijPDTR6sRHoQL

47wHMr2Yj80VZGgkCSLAkL88ACz9TfUiVFhtfl6xMC2yuFl+WRk1XfF5VtWe5Zer

3Fn1DcBmlF7O86XUkiSHP4EV0cI6n5ZMzVLx0XAUtdAl1gD94y1V+6p9PcQHLyQA

pGRmj5IlSFw90aLafgCTbRbmC0ChIqHy91UFa1ub0130+yu7LsLGRlPmJ9NE61JR

bjRhlUXItRYWY7C4M3m/0wz6fmVQNSumJM08RHq6lUB3olzIgGIZlZkoaESrLG0p

qq2AENFemCPF0uhyVS2humMHjWuRr+jedfc/IMl7sLEgAdqCVCfV3RZVEaNXBud1

4QjkuTrwaTcRXVFbtrVioT/puyVUlpA7+k7w+F5TZwUV08mwvUEqDw==

-----END RSA PRIVATE KEY-----

quit

% Enter PEM-formatted SIGNATURE certificate.

% End with a blank line or "quit" on a line by itself.

! Paste the CA cert from .pem archive again.