When configuring PKI, go to these sections for information you are
interested in:
l
Introduction to PKI
l
PKI Configuration Task List
l
Displaying and Maintaining
PKI
l
PKI Configuration Examples
l
Troubleshooting PKI
1.1 Introduction
to PKI
This section covers these topics:
l
PKI
Overview
l
PKI
Terms
l
Architecture
of PKI
l
Applications
of PKI
l
Operation
of PKI
Public Key Infrastructure (PKI) is a system
designed for providing information security through public key technologies and
digital certificates and verifying the identities of the digital certificate
owners.
PKI employs digital certificates, which are
bindings of certificate owner identity information and public keys. PKI allows
users to request certificates, use certificates, and revoke certificates. By
leveraging digital certificates and relevant services like certificate distribution
and blacklist publication, PKI supports authentication the entities involved in
communication, and thus guaranteeing the confidentiality, integrity and
non-repudiation of data.
1.1.2 PKI Terms
I. Digital certificate
A digital certificate is a file signed by a
certificate authority (CA) that contains a public key and the related user identity
information. A simplest digital certificate contains a public key, an entity
name, and a digital signature from the CA. Generally, a digital certificate
also includes the validity period of the key, the name of the CA and the sequence
number of the certificate. A digital certificate must comply with the international
standard of ITUTX.5.9. This manual involves two types of certificates: local
certificate and CA certificate. A local certificate is a digital certificate signed
by a CA for an entity, while a CA certificate, also known as root certificate,
is signed by the CA for itself.
II. CRL
An existing certificate may need to be
revoked when, for example, the user name changes, the private key leaks, or the
user stops the business. Revoking a certificate is to remove the binding of the
public key with the user identity information. In PKI, the revocation is made
well known through certificate revocation lists (CRLs). Whenever a certificate
is revoked, the CA publishes one or more CRLs to announce that the certificate
is invalid. The CRLs contains the serial numbers of all certificates that are revoked
and function an effective way for checking the validity of certificates.
A CA may publish multiple CRLs when the
number of revoked certificates is so large that publishing them in a single CRL
may degrade network performance.
III. CA policy
A CA policy is a set of criteria that a CA follows
in managing certificate requests and in issuing, revoking, and publishing CRLs.
Usually, a CA advertises its policy in the form of certification practice
statement (CPS), which can be acquired through out-of-band means such as phone,
disk, and e-mail or through other means. Since different CAs may use different methods
to check the binding of a public key with an entity, make sure that you
understand the CA policy before selecting a trusted CA for certificate request.
1.1.3 Architecture of PKI
A PKI system consists of entities, a CA, a registration
authority (RA) and a PKI repository, as shown in Figure 1-1.
Figure 1-1 PKI
architecture
I. Entity
An entity is
an end user of PKI products or services, such as a person, an organization, a device
like a switch, or a process running on a computer.
II. CA
A CA is a trusted entity responsible for
issuing and managing digital certificates. A CA issues certificates, specifies the
validity period of a certificate, and revokes a certificate as needed by
publishing CRLs.
III. RA
A registration authority (RA) is an
extended part of a CA or an independent authority. An RA can implement
functions including identity authentication, CRL management, key pair
generation and key pair backup. The PKI standard recommends that an independent
RA be used for registration management to achieve higher security of
application systems.
IV. PKI repository
A PKI repository includes a Lightweight Directory
Access Protocol (LDAP) server and some common databases that stores and manages
information like certificate requests, certificates, keys, CRLs and logs while
providing a simple query function.
LDAP is a protocol for accessing and
managing PKI information. An LDAP server stores user information and digital
certificates from the RA server and provides directory navigation service. From
an LDAP server, an entity can retrieve local and CA certificates of its own as
well as certificates of other entities.
1.1.4 Applications
of PKI
The PKI technology can satisfy the security
requirements of online transactions. As an infrastructure, PKI has a wide range
of applications. Here are some application examples.
I. VPN
A virtual private network (VPN) is a
proprietary data communication network built over the public communication
infrastructure. A VPN can leverage network layer security protocols (for
instance, IPSec) in conjunction with PKI-based encryption and digital signature
technologies for confidentiality.
II. Secure E-mail
E-mails also require confidentiality,
integrity, authentication, and non-repudiation. PKI can address these needs. The
secure E-mail protocol that is currently developing rapidly is Secure/Multipurpose
Internet Mail Extensions (S/MIME), which is based on PKI and allows for
transfer of encrypted mails and mails with signature.
III. Web security
For Web security, two peers can establish a
Secure Sockets Layer (SSL) connection first for transparent and secure
communications at the application layer. With PKI, SSL enables communications
with encryption between a browser and a server. Both the communication parties
can identify the identity of each other through digital certificates.
1.1.5 Operation of PKI
In a PKI-enabled network, an entity can
request a local certificate from the CA and the device can check the validity
of certificates. Here is how it works:
1)
An entity submits a certificate request to the
CA.
2)
RA reviews the identity of the entity and then
sends the identity information and the public key with a digital signature to
the CA.
3)
The CA validates the digital signature, approves
the application, and issues a certificate.
4)
The RA receives the certificate from the CA,
sends it to the LDAP server to provide directory navigation service, and
notifies the entity that the certificate is successfully issued.
5)
The entity retrieves the certificate. With the
certificate, the entity can communicate with other entities safely through
encryption and digital signature.
6)
The entity makes a request to the CA when it
needs to revoke its certificate, while the CA approves the request, updates the
CRLs and transfers the CRLs to the LDAP server.
1.2 PKI Configuration Task List
Complete the following tasks to configure PKI:
1.3 Configuring an Entity DN
A certificate is the binding of a public
key and the identity information of an entity, where the identity information is
identified by an entity distinguished name (DN). A CA identifies a certificate
applicant uniquely by entity DN.
An entity DN is defined by these parameters:
l
Common name of the entity.
l
Country code of the entity, a standard
2-character code. For example, CN represents China and US represents the United
States of America.
l
Fully qualified domain name (FQDN) of the entity,
a unique identifier of an entity on the network. It consists of a host name and
a domain name and can be resolved to an IP address. For example,
www.whatever.com is an FQDN, where www is a host name and whatever.com a domain
name.
l
IP address of the entity.
l
Locality where the entity resides.
l
Organization to which the entity belongs.
l
Unit of the entity in the organization.
l
State where the entity resides.
The configuration
of an entity DN must comply with the CA certificate issue policy. You need to
determine, for example, which entity DN parameters are mandatory and which are optional.
Otherwise, certificate request may be rejected.
Follow these steps to configure an entity DN:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Create an entity and enter its view
|
pki entity
entity-name
|
Required
No entity exists by default.
|
|
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 for the entity
|
fqdn name-str
|
Optional
No FQDN 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 of 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 or province is specified by
default.
|
l
Currently, up to two entities can be created on
a device.
l
Windows 2000 CA server has some restrictions on
the data length of a certificate request. If the entity DN in a certificate
request goes beyond a certain limit, the server does not respond to the certificate
request.
1.4 Configuring a PKI Domain
Before requesting a PKI certificate, an
entity needs to be configured with some enrollment information, which is
referred to as a PKI domain. A PKI domain is intended only for convenience of
reference by other applications, and has only local significance.
A PKI domain is defined by these parameters:
l
Trusted CA
An entity requests a certificate from a trusted
CA.
l
Entity
A certificate applicant uses an entity to provide
its identity information to a CA.
l
RA
Generally, an independent RA is in charge
of certificate request management. It receives the registration request from an
entity, checks its qualification, and determines whether to ask the CA to sign
a digital certificate. The RA only checks the application qualification of an entity;
it does not issue any certificate. Sometimes, the registration management
function is provided by the CA, in which case no independent RA is required. You
are recommended to deploy an independent RA.
l
URL of the enrollment server
An entity sends a certificate request to
the enrollment server through Simple Certification Enrollment Protocol (SCEP),
a dedicated protocol for an entity to communicate with a CA.
l
Polling interval and count
After an applicant makes a certificate
request, the CA may need a long period of time if it verifies the certificate
request manually. During this period, the applicant needs to query the status of
the request periodically to get the certificate as soon as possible after the
certificate is signed. You can configure the polling interval and count to
query the request status.
l
IP address of the LDAP server
An LDAP server is usually deployed to store
certificates and CRLs. If this is the case, you need to configure the IP
address of the LDAP server.
l
Fingerprint for root certificate validation
Upon receiving the root certificate of the
CA, an entity needs to validate the fingerprint of the root certificate,
namely, the hash value of the root certificate content. 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 the one configured for the
PKI domain.
Follow these steps to configure a PKI
domain:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Create a PKI domain and enter its view
|
pki domain domain-name
|
Required
No PKI domain exists by default.
|
|
Specify the trusted CA
|
ca identifier name
|
Required
No trusted CA is specified by default.
|
|
Specify the entity for certificate
request
|
certificate request entity entity-name
|
Required
No entity is specified by default.
The specified entity must exist.
|
|
Specify the authority for certificate
request
|
certificate request from { ca | ra }
|
Required
No authority is specified by default.
|
|
Configure the URL of the server for certificate
request
|
certificate request url url-string
|
Required
No URL is configured by default.
|
|
Configure the polling interval and maximum
number of attempts for querying the certificate request status
|
certificate request polling { count count | interval minutes }
|
Optional
The polling is executed for up to 50
times at the interval of 20 minutes by default.
|
|
Specify the LDAP server
|
ldap-server ip ip-address [ port port-number ] [ version
version-number ]
|
Optional
No LDP server is specified by default.
|
|
Configure the fingerprint for root
certificate validation
|
root-certificate fingerprint { md5 | sha1 } string
|
Optional
No fingerprint is configured by default.
|
l
Currently, up to two PKI domains can be created
on a device.
l
The CA name is required only when you retrieve a
CA certificate. It is not used when in local certificate request.
1.5 Submitting a PKI Certificate Request
When requesting a certificate, an entity introduces
itself to the CA by providing its identity information and public key, which
will be the major components of the certificate that the CA may issue to the
entity. A certificate request can be submitted to a CA in two ways: online and
offline. In offline mode, a certificate request is submitted to a CA by an “out-of-band”
means such as phone, disk, or e-mail.
Online certificate request falls into two
categories: manual mode and auto mode.
1.5.1 Submitting a Certificate Request in Auto
Mode
In auto mode, an entity automatically
requests a certificate through the SCEP protocol when it has no local
certificate or the present certificate is about to expire.
Follow these steps to configure an entity
to submit a certificate request in auto mode:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter PKI domain view
|
pki domain domain-name
|
—
|
|
Set the certificate
request mode to auto
|
certificate
request mode auto [ key-length key-length
| password { cipher | simple } password
] *
|
Required
Manual by
default
|
1.5.2 Submitting a Certificate Request in Manual
Mode
In manual mode, you need to retrieve a CA
certificate, generate a local RSA key pair, and submit a local certificate request
for an entity.
The goal of retrieving a CA certificate is
to verify the authenticity and validity of a local certificate.
Generating an RSA key pair is an important
step in certificate request. The key pair includes a public key and a private
key. The private key is kept by the user, while the public key is transferred
to the CA along with some other information. For detailed information about RSA
key pair configuration, refer to SSH Configuration.
Follow these steps to submit a certificate
request in manual mode:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter PKI domain view
|
pki domain
domain-name
|
—
|
|
Set the certificate request mode to manual
|
certificate request mode manual
|
Optional
Manual by default
|
|
Return to system view
|
quit
|
—
|
|
Retrieve a CA certificate manually
|
Refer to Retrieving a Certificate Manually
|
Required
|
|
Generate a local RSA key pair
|
public-key local create rsa
|
Required
No local RSA key pair exists by default.
|
|
Submit a local certificate request
|
pki request-certificate domain domain-name
[ password ] [ pkcs10 [ filename filename ] ]
|
Required
|
l
If a PKI domain has already a local certificate,
creating an RSA key pair will result in inconsistency between the key pair and
certificate. To generate a new RSA key pair, delete the local certificate and
then issue the public-key local create rsa command.
l
A newly created key pair will overwrite the
existing one. If you perform the public-key local create rsa command in
the presence of a local RSA key pair, the system will ask you whether you want
to overwrite the existing one.
l
If a PKI domain has already a local certificate,
you cannot request another certificate for it. This is to avoid inconsistency
between the certificate and the enrollment information resulting from
configuration changes. To request a new certificate, use the pki
delete-certificate command to delete the existing local certificate and the
CA certificate stored locally.
l
When it is impossible to request a certificate
from the CA through SCEP, you can save the request information by using the pki
request-certificate domain command with the pkcs10 and filename
keywords, and then send the file to the CA by an out-of-band means.
l
Make sure the clocks of an entity and the CA are
synchronous. Otherwise, the validity period of the certificate may be abnormal.
l
The pki request-certificate domain configuration
will not be saved in the configuration file.
1.6 Retrieving a Certificate Manually
You can download an existing CA certificate
or local certificate from the CA server and save it locally. To do so, you can
use two ways: online and offline. In offline mode, you need to retrieve a
certificate by an out-of-band means like FTP, disk, e-mail and then import it into
the local PKI system.
Certificate retrieval serves two purposes:
l
Locally store the certificates associated with
the local security domain for improved query efficiency and reduced query
count;
l
Prepare for certificate validation.
Before retrieving a local certificate, be
sure to complete LDAP server configuration.
Follow these steps to retrieve a
certificate manually:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Retrieve a
certificate manually
|
Online
|
pki
retrieval-certificate { ca | local }
domain domain-name
|
Required
Use either
command
|
|
Offline
|
pki
import-certificate { ca | local } domain domain-name { der | p12 |
pem } [ filename filename ]
|
Caution:
l
If a PKI domain has already a CA certificate,
you cannot retrieve another CA certificate for it. This is in order to avoid
inconsistency between the certificate and enrollment information due to related
configuration changes. To retrieve a new CA certificate, use the pki
delete-certificate command to delete the existing CA certificate and local
certificate first.
l
The pki retrieval-certificate
configuration will not be saved in the configuration file.
A certificate needs to be validated before
being used. Validating a certificate is to check that the certificate is signed
by the CA and that the certificate has neither expired nor been revoked.
Before validating a certificate, you need
to retrieve the CA certificate.
You can specify whether CRL checking is
required in certificate validation. If you enable CRL checking, CRLs will be
used in validation of a certificate.
I. Configuring CRL-checking-enabled
PKI certificate validation
Follow these steps to configure CRL-checking-enabled
PKI certificate validation:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter PKI domain view
|
pki domain domain-name
|
—
|
|
Specify the URL of the CRL distribution
point
|
crl url url-string
|
Optional
No CRL
distribution point URL is specified by default.
|
|
Set the CRL update period
|
crl update-period hours
|
Optional
By default, the CRL update period depends
on the next update field in the CRL file.
|
|
Enable CRL checking
|
crl check enable
|
Optional
Enabled by default
|
|
Return to system view
|
quit
|
—
|
|
Retrieve the CA certificate
|
Refer to Retrieving a Certificate
Manually
|
Required
|
|
Retrieve CRLs
|
pki retrieval-crl domain domain-name
|
Required
|
|
Verify the validity of a certificate
|
pki validate-certificate { ca | local } domain domain-name
|
Required
|
II. Configuring CRL-checking-disabled
PKI certificate validation
Follow these steps to configure CRL-checking-disabled
PKI certificate validation:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter PKI domain view
|
pki domain domain-name
|
—
|
|
Disable CRL checking
|
crl check disable
|
Required
Enabled by default
|
|
Return to system view
|
quit
|
—
|
|
Retrieve the CA certificate
|
Refer to Retrieving a Certificate
Manually
|
Required
|
|
Verify the validity of the certificate
|
pki validate-certificate { ca | local } domain domain-name
|
Required
|
l
The CRL update period refers to the interval at
which the entity downloads CRLs from the CRL server. The CRL update period
configured manually is prior to that specified in the CRLs.
l
The pki retrieval-crl domain configuration
will not be saved in the configuration file.
