Throughout this
chapter, the term router refers to a layer 3 switch that has implemented
routing protocols.
When configuring PKI, go to these sections
for information you are interested in:
l
Introduction to PKI
l
Implementation of PKI in
Devices
l
PKI Configuration Task List
l
Configuring Entity Name
Space
l
Creating a PKI Domain
l
Configuring Parameters for
a PKI Domain
l
Submitting a PKI Certificate
Request
l
Retrieving a Certificate
Manually
l
Configuring PKI Certificate
Validation
l
Destroying a Local RSA Key
Pair
l
Deleting a Certificate
l
Configuring Access Control
Policy of Certificate Attribute
l
Displaying and Maintaining
PKI
l
Typical Configuration Examples
l
Troubleshooting
1.1 Introduction
to PKI
Public key infrastructure (PKI) is a system
designed for providing information security with public key technologies and
digital certificate and verifying the identities of the digital certificate
owners. A collection of hardware and software systems and security policies,
PKI offers a whole set of security mechanisms.
PKI is designed to bind the certificate
owner’s identity with the related key pair by signing a digital
certificate to the public key and the corresponding user identity information. This
facilitates users to acquire certificates, access certificate issuing
environment and announce the revocation of certificates. By leveraging digital
certificates and relevant diverse services (for instance, certificate issuing
and blacklist publication), you can authenticate the identities of the entities
involved in the communications, and thus guaranteeing the confidentiality,
integrity and non-repudiation of communication data.
I. Digital certificate
Digital certificate is a file signed by
certificate authority (CA), including public key and related user identity
information. A simplest certificate contains a public key, the name of a user
or device, and the digital signature from the CA. A certificate generally
includes the lifetime of the secret key, CA name and the sequence number of the
certificate. A certificate is ITUTX.5.9-compliant. This article involves two
types of certificates: local certificate and CA certificate. Local certificate
is a digital certificate that CA signs to an entity; CA certificate, also known
as root certificate, is a digital certificate signed by the CA itself.
II. Certificate revocation list
It is necessary to provide a way of
removing the bundle of public key and the related user identity information to
revoke the existing certificate for many reasons, for example, the user name is
changed, the private key is intercepted or the operation is aborted. In PKI,
this concept is called certificate revocation list (CRL). Once a certificate is
revoked, the CA releases a CRL to announce that the certificate is invalid. The
CRL also contains an entry of the serial numbers of invalid certificates. CRL provides
an effective way to check the validity of certificates for applications and
other systems.
III. Lightweight directory access protocol
server
Lightweight directory access protocol (LDAP)
provides a means to access PKI repository, with the purpose of accessing and managing
PKI information. LDAP server supports directory navigation, and enlists user
information and digital certificates from a RA server. Then you can acquire your
certificate or others’ certificates when accessing the LDAP server.
1.1.3 System Architecture
A PKI system consists of terminal entity,
CA, registration authority (RA) and PKI repository, as follows:
Figure 1-1 PKI
architecture
I. Terminal entity
Terminal entity is the end user of PKI
products or services. It can be person, organizations, devices (for instance
router or switch) or the progresses running on the computers.
II. CA
CA is a trusted entity responsible for the
issuing and management of digital certificates. In addition, it can issue
certificates to person and participating network devices, specify the period of
validity for a certificate, and revoke a certificate as needed by releasing a
CRL.
Security domain refers to a trust
relationship that an enterprise or organization establishes through relevant
PKI products. In a security domain, entities enjoy a set of secret key
management, certificate management and policy management services available
from PKI. PKI also allows an organization to establish trust relationship with
other security domains through many ways, like certificate level or cross
authentication.
III. Registration authority
Registration authority (RA) is the extension
of CA. RA can implement many functions such as identity authentication, CRL management,
secret key generation and key pair backup. PKI standard recommends that an
independent RA is responsible for registration management for higher security
of application systems.
IV. PKI repository
PKI repository includes LDAP server and
general databases that stores and manages the information like request,
certificate, secret key, CRL and log while providing a certain query function.
1.1.4 Applications
PKI technology can satisfy the security
requirements of online transactions. As an infrastructure, PKI is pervasive and
in the continuous evolvement. Here are some application examples:
I. Virtual private network
Virtual private network (VPN) is a proprietary
data communication network built upon the public communication infrastructure,
which leverages network layer security protocols (especially IPSec) and
PKI-enabled encryption and signature technologies for confidentiality.
II. Secure E-mail
E-mail also requires confidentiality, integrity,
authentication and non-repudiation. With PKI technology, you can enable these
functions. Today, the rapidly developed secure E-mail protocol is The Secure Multipurpose
Internet Mail Extension (S/MIME), a protocol allowing for the transfer of the
encrypted mails and the mails with signature. PKI provides a foundation for the
implementation of S/MIME.
III. Web security
For Web security, two entities in the
communication need to establish a secure sockets layer (SSL) connection first
for transparent and secure communications on the application layer. With PKI
technology, SSL enables communications with encryption between a browser and a
server. Both the communication parties can identify the identity of the peer
through digital certificate.
1.2 Implementation of PKI in Devices
In a PKI-enabled network, an entity can
request a local certificate from CA and then check the validity of the
certificate.
I. Applying for and revoking a
certificate
1)
You can apply for a certificate from CA in two
ways: online and offline. In offline application mode, the user provides
application information to CA through phone, disk and E-mail and so on.
2)
RA reviews the user identity, and then sends the
identity information with public key in form of digital signature to CA.
3)
CA validates the digital signature, approves the
application and issues a certificate.
4)
RA receives the certificate from CA, sends it to
the LDAP server to provide directory navigation service, and notifies the user
of the success in certificate issuing.
5)
The user acquires the certificate. In addition,
with the certificate, the user can safely communicate with other entities
through encryption and digital signature.
6)
The user makes a request to CA when he or she needs
to revoke its certificate,CA approves the request, updates the CRL and
propagates to the LDAP server.
II. Using a certificate
1)
Obtaining a certificate
In real circumstances, to validate the
digital signature of messages, the user must obtain the public key certificate
from the sender for the purpose of decrypting and validating messages. At the
same time, the user must obtain CA certificate to validate the certificate
issued by the sender so as to confirm the sender’s identity.
2)
Validating a certificate
When it comes to certificate validation,
you need to verify the time of the signature, the signatory profile and the
validity of the certificate. The kernel of the matter is to examine the
signature on the certificate from CA, as well as ensure that the certificate is
still in the period of validity and not revoked. For example, a user has
received an E-mail with a certificate which contains public key. This
certificate is signed with private key. It is necessary to validate the
certificate to check whether the user owns the certificate legally, and whether
the certificate is valid (by CRL) and trustful.
Table 1-1 Introduction to PKI Configuration Task
1.4 Configuring Entity Name Space
Entity name space refers to a collection of
components used to name an entity. CA details an entity with the information it
thinks of important, and uses a unique identifier (i.e. DN, Distinguished-Name)
to identify an entity.
DN consists of many components as follows:
l
Common name;
l
Country code, a standard 2-character code. For example,
CN represents China and US represents America;
l
Fully qualified domain name (FQDN), a unique
identifier of an entity across a network. It consists of a host name and a
domain name and can be resolved an IP address. For example, www.whatever.com is
a FQDN, where www is a host name and whatever.com is a domain name;
l
IP address;
l
Locality;
l
Organization;
l
Unit;
l
State.
Entity
configuration information must comply with CA certificate issue policy, for
example, to determine mandatory and optional parameters. Otherwise, certificate
request may be rejected.
Follow these steps to configure entity name
space:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Configure an entity name and
enter its view
|
pki entity name
|
—
|
|
Configure the common name for the
entity
|
common-name name
|
Optional
No common name is specified by
default.
|
|
Configure the country code for
the entity
|
country country-code-str
|
Optional
No country code is specified by
default.
|
|
Configure the FQDN name for the
entity
|
fqdn name-str
|
Optional
No FQDN name is specified by
default.
|
|
Configure the IP address for the
entity
|
ip
ip-address
|
Optional
No IP address is specified by
default.
|
|
Configure the locality for the
entity
|
locality locality-name
|
Optional
No locality is specified by
default.
|
|
Configure the organization name for the entity
|
organization org-name
|
Optional
No organization is specified by
default.
|
|
Configure the unit name for the
entity
|
organization-unit org-unit-name
|
Optional
No unit is specified by default.
|
|
Configure the state or province for
the entity
|
state state-name
|
Optional
No state is specified by default.
|
l
An entity name is just for reference, not for
any field of a certificate. Now at most two entities can be defined on a
device.
l
Windows 2000 CA server has some restrictions on the
data length of certificate request. If the configured entity name goes beyond a
certain limit, the server does not respond to certificate request.
1.5 Creating a PKI Domain
A PKI domain configured on a device is
invisible to CA and other devices. It locally does not involve user management
and the relationship between users. Every PKI domain has its own parameters. The
goal is to facilitate other applications to refer PKI configuration, like SSL.
Follow these steps to create a PKI domain:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Create a PKI domain and enter the
domain view
|
pki domain
name
|
Required
No PKI domain exists by default.
|
Today, a device
supports only two PKI domains. If you need to create a domain in the presence
of two PKI domains, you should use the corresponding undo command to delete the
old one.
An entity needs to be configured with some
enrollment messages before requesting a PKI certificate. A PKI domain is the
collection of these messages.
A PKI domain includes the following
parameters:
l
Name of a trusted CA
A CA that an entity trusts is responsible
for certificate issuing in the process of certificate request. So it is
necessary to specify the name of a trusted CA.
l
Name of an entity
An entity must be configured with a name
used to indicate its identity when it requests a certificate from CA.
l
RA for certificate request
An independent registration authority (RA)
is in charge of the management of certificate request: accept the registration
request from an entity, check its qualification, and determine whether to agree
with CA to sign a digital certificate. RA only checks the entity’s
application qualification, not issue a certificate. Sometimes, CA takes over
the registration management function of PKI. In this case, an independent RA is
not required. This does not mean that the registration management function of
PKI is cancelled. Instead, it is thought of as a function of CA.
l
URL of enrollment server
It is necessary to configure the URL for
the enrollment server before certificate request. Then an entity can make a
certificate request to the server through simple certification enrollment
protocol (SCEP), a protocol specially designed for communication with CA.
l
Polling interval and count
When an entity makes a certificate request
to a CA, it takes a long time for the CA to issue a certificate if it verifies
the certificate request manually. During this period, the entity needs to query
the request status periodically so that it can acquire the certificate as soon
as the certificate is signed. An entity can configure the polling interval and
count for certificate request status.
l
IP address of LDAP server
How to store certificate and CRL messages
in a PKI system is a matter of the utmost concern. LDAP server is generally
used to solve this problem. At this point, you need to locate LDAP server.
l
Fingerprint for root certificate validation
An entity needs to validate the fingerprint
of the root certificate when it acquires the root certificate from CA, namely,
the hash value of the root certificate contents. This hash value is unique to
every certificate. The entity will reject the root certificate if the
fingerprint of the root certificate does not match with the configured value.
Follow these steps to configure parameters
for PKI domain:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter PKI domain view
|
pki domain name
|
—
|
|
Configure the name for a trusted
CA
|
ca identifier name
|
Required
No trusted CA is configured by
default.
|
|
Specify the name for an entity
|
certificate request entity entity-name
|
Required
No entity name is specified by
default.
|
|
Configure RA for certificate
request
|
certificate request from { ca | ra }
|
Required
No RA is configured by default.
|
|
Configure the URL for enrollment
server
|
certificate request url url-string
|
Required
No URL is configured by default.
|
|
Configure polling interval and
count for certificate request
|
certificate request polling { count count | interval minutes }
|
Optional
The polling is executed for 50
times at the interval of 20 minutes by default.
|
|
Configure the IP address for LDAP
server
|
ldap-server ip ip-address [ port port-number ] [ version
version-number ]
|
Optional
No IP address is configured by
default.
|
|
Configure the fingerprint for
root certificate validation
|
root-certificate fingerprint { md5 | sha1 } string
|
Optional
No fingerprint is configured by
default.
|
l
CA policy means a set of standards that CA
adopts to manage certificate requests, issue certificates, revoke certificates
and post CRL. In general, CA policy is advertised in the format of
certification practice statement (CPS). In addition, you can get CA policy
through phone, disk, e-mail or other methods. The methods used to check the
bundle of public keys and entities vary with CAs. So it is all the more
important to understand its policy when you select a trusted CA to request a
certificate.
l
CA name is only required when you retrieve a CA
certificate, not for a local certificate.
1.7 Submitting a PKI Certificate Request
Certificate request is a process of an
entity introducing itself to CA. An entity provides CA with its identity and
the corresponding public key. These messages are the major components of the
certificate that CA issues to the entity. An entity can submit a certificate
request to CA in two ways: online and offline. In offline mode, an entity can
submit a request to CA out-of-band (for example, phone, disk or e-mail).
Online certificate request falls into two
categories: manual and automatic.
1.7.1 Submitting a Certificate Request
Automatically
In automatic mode, an entity will
automatically request a certificate through the SCEP protocol in the absence of
a local certificate. Moreover, it will automatically request a new certificate
when the existing one is about to expire.
Follow these steps to configure submitting
a certificate request automatically:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter PKI domain view
|
pki domain name
|
—
|
|
Submit
a certificate request automatically
|
certificate request mode auto [
key-length key-length | password { cipher |
simple } password ] *
|
Required
Manual
mode is adopted by default.
|
1.7.2 Submitting a Certificate Request
Manually
In manual
mode, an entity needs to retrieve a CA certificate, generate a local RSA key
pair and request a local certificate manually.
The goal of
retrieving a CA certificate is to verify the authenticity and validity of a
local certificate.
The generation of a RSA key pair is the key
for certificate request. A pair of keys is used in the process of certificate
request: public key and private key. The private key is held by the user, while
the public key and other information are transferred to CA to sign a
certificate.
Follow these steps to configure submitting
a certificate request manually:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter PKI domain view
|
pki domain name
|
—
|
|
Submit a certificate request
manually
|
certificate request mode manual
|
Optional
Manual is adopted by default
|
|
Return system view
|
quit
|
—
|
|
Retrieve a CA certificate
manually
|
Refer to1.8 Retrieving a Certificate Manually
|
Required
|
|
Generating a local RSA key pair
|
rsa local-key-pair create
|
Required
No local RSA key pair exists by
default.
|
|
Retrieve a local certificate
manually
|
pki request-certificate domain domain-name
[ password ] [ pkcs10 [ filename filename ] ]
|
Required
|
l
If a local certificate already exists, you are
not recommended to create another RSA key pair to avoid inconsistency between
the key pair and the existing certificate. To generate a new RSA key pair,
delete the local certificate and then run the rsa local-key-pair create command.
l
When you run the rsa local-key-pair create
command, the system will prompt whether the resulted RSA key pair overwrites
the existing one in the presence of a local RSA key pair.
l
If a local certificate already exists, requesting
another certificate is prohibited to avoid inconsistency between the certificate
and the registration information resulted from configuration changes. To
request a new certificate, use the pki delete-certificate command to delete
the existing local certificate and the CA certificate locally stored.
l
If you cannot retrieve a certificate from CA in
online mode through the SCEP protocol, you can select the parameter pkcs10
to print the request information. Then you can save it and send one copy to CA out-of-band.
l
Make sure the clocks of an entity and CA are
synchronous before certificate request. Otherwise, the period of the certificate
validity may be abnormal.
l
The pki request-certificate domain command
will not be saved in the configuration.
1.8 Retrieving a Certificate Manually
You can download an existing CA certificate
or local certificate locally.
For certificate retrieval, two ways are
supported: online and offline. In offline mode, you need to retrieve a
certificate out-of-band (for instance, FTP, disk, e-mail) and then import it
locally.
Certificate retrieval serves two purposes:
l
Locally store the certificate associated with
the local security domain for improved query efficiency and reduced query
count;
l
Prepare for certificate validation.
Follow these steps to retrieve a
certificate:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Retrieve a
certificate manually
|
Online
|
pki
retrieval-certificate { ca | local }
domain domain-name
|
Use either
command
|
|
Offline
|
pki
import-certificate { ca | local } domain domain-name { der | p12 | pem
} [ filename filename ]
|
Caution:
l
If a CA certificate already exists locally, you
are not recommended to run this command to avoid inconsistency between the
certificate and enrollment information duo to related configuration changes. To
reqtrieve a new certificate, use the pki delete-certificate command to delete
the existing CA certificate and local certificate.
l
The pki retrieval-certificate command
will not be saved in the configuration.
1.9 Configuring PKI Certificate Validation
It is necessary to check the corresponding
CRL before using a certificate. In real configuration, you should first
download CA certificate locally, and then perform the following configuration
to check the validity of the CA certificate or local certificate.
Follow these steps to configure PKI
certificate validation:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter domain view
|
pki domain
name
|
—
|
|
Configure the URL for the CRL
distribution point
|
crl url url-string
|
Required
No URL is specified by default.
|
|
Configure CRL update period
|
crl update-period hours
|
Optional
The CRL is updated by its next update
domain by default.
|
|
Enable/disable CRI check
|
crl check {
disable | enable }
|
Optional
Enabled by default
|
|
Return to system view
|
quit
|
—
|
|
Retrieve a CA certificate
|
Refer to 1.8 Retrieving a Certificate Manually
|
Required
|
|
Retrieve a CRL and download it locally
|
pki retrieval-crl domain domain-name
|
Required
|
|
Verify the validity of a certificate
|
pki validate-certificate { ca | local } domain domain-name
|
Required
|
l
CRL update period refers to the interval of
downloading a CRL from CRL access server to a local machine. CRL update period
configured manually is prior to that specified in the CRL.
l
CRL is not saved in configuration.
1.10 Destroying a Local RSA Key Pair
When the private key leaks or the current
certificate is about to expire, you have to delete the old key pair. As a
result, a new key pair can be generated for requesting a certificate.
Follow these steps to destroy a local RSA
key pair:
