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.

1.1.2 Glossary

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.

1.3 PKI Configuration Task List

Table 1-1 Introduction to PKI Configuration Task

Configuration Task		Remarks
Configuring Entity Name Space		Required
Creating a PKI Domain		Required
Configuring Parameters for a PKI Domain		Required
Submitting a PKI Certificate Request	Submitting a Certificate Request Automatically	Use either command
Submitting a PKI Certificate Request	Submitting a Certificate Request Manually	Use either command
Retrieving a Certificate Manually		Optional
Configuring PKI Certificate Validation		Optional
Destroying a Local RSA Key Pair		Optional
Deleting a Certificate		Optional
Configuring Access Control Policy of Certificate Attribute		Optional

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.

& Note:

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.

& Note:

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.

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.

& Note:

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.

1.6 Configuring Parameters for a PKI Domain

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.

& Note:

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

& Note:

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
Retrieve a certificate manually	Offline	pki import-certificate { ca \| local } domain domain-name { der \| p12 \| pem } [ filename filename ]	Use either command

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

& Note:

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:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Destroy an RSA key pair	rsa local-key-pair destroy	Required

1.11 Deleting a Certificate

You can delete an existing local certificate or CA certificate.

Follow these steps to delete a certificate:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Delete a certificate	pki delete-certificate { ca \| local } domain domain-name	Required

1.12 Configuring Access Control Policy of Certificate Attribute

By configuring an access control policy based on certificate attributes, you can take further control of access privilege on the customer premises, guaranteeing the security of servers.

Follow these steps to configure an access control policy based on certificate attributes:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a certificate attribute group and enter its view	pki certificate attribute-group group-name	Required No certificate attribute group is specified by default
Configure a rule for the certificate issuer name, certificate subject name and alternative subject name	attribute id { alt-subject-name { fqdn \| ip } \| { issuer-name \| subject-name } { dn \| fqdn \| ip } } { ctn \| equ \| nctn \| nequ} attribute-value	Optional No restriction on the issuer name, certificate subject name and alternative subject name exists by default.
Return to system view	quit	—
Create an access control policy for certificate attributes and enter its view	pki certificate access-control-policy policy-name	Required No access control policy is specified by default.
Configure an access control rule for certificate attributes	rule [ id ] { deny \| permit } group-name	Optional No access control rule is specified by default.

Caution:

l The alternative certificate subject attribute does not appear as a domain name, so there is no dn in the configuration.

l The group-name must be the name of an existing certificate attribute group when you configure an access control rule for certificate attributes.

1.13 Displaying and Maintaining PKI

Follow these steps to display and maintain PKI:

To do…	Use the command…	Remarks
Display certificate	display pki certificate { { ca \| local } domain domain-name \| request-status }	Available in any view
Display CRL	display pki crl domain domain-name	Available in any view
Display the information of the certificate attribute group	display pki certificate attribute-group { group-name \| all }	Available in any view
Display the information of the certificate attribute access control policy	display pki certificate access-control-policy { policy-name \| all }	Available in any view

& Note:

l The format and fields of a certificate are X.509-compliant, including all kinds of user- and CA-related information, such as user email address, public key of the certificate holder; issuer, serial number, and validity (period) of the certificate, etc.

l CRL complies with X.509 standard, covering version, signature algorithm, issuer name, last update date, next update date, user public key, signature value, serial number, and revocation date, etc.

1.14 Typical Configuration Examples

Caution:

l When a server running Windows operating system is used as the CA, the Simple Certificate Enrollment Protocol plugin is required. In this case, you need to specify the entity to apply for the certificate from RA by using the certificate request from ra command when configuring the PKI domain.

l The Simple Certificate Enrollment Protocol plugin is not needed when RSA Keon software is used. In this case, you need to specify the entity to apply for the certificate from CA by using the certificate request from ca command when configuring the PKI domain.

l This section assumes RSA Keon software is used on the CA server.

1.14.1 PKI Entity Requests a Certificate from CA

I. Network requirements

Perform the corresponding configuration on the device as a PKI entity to satisfy the following requirements:

l The device makes a local certificate request to RSA CA server;

l The device acquires CRL to prepare for certificate validation.

II. Network diagram

Figure 1-2 Network diagram for PKI entity which requests a certificate from CA

III. Configuration procedure

On the device, perform the following configuration:

1) Configure entity name space.

# Specify the entity name as ant and the common name as 1.

<Sysname> system-view

[Sysname] pki entity ant

[Sysname-pki-entity-ant] common-name 1

[Sysname-pki-entity-ant] quit

2) Configure the parameters for the PKI domain.

# Create PKI domain torsa and enter its view.

[Sysname] pki domain torsa

# Specify the name of the trusted CA as rsa.

[Sysname-pki-domain-torsa] ca identifier rsa

# Configure the URL of the enrollment server.

[Sysname-pki-domain-torsa] certificate request url http://4.4.4.133:446/6953bf7fb5b1cf514376243ce67ebed1209c292a

# Configure CA.

[Sysname-pki-domain-torsa] certificate request from ca

# specify the entity name as ant.

[Sysname-pki-domain-torsa] certificate request entity ant

# Configure the URL for the CRL distribution point.

[Sysname-pki-domain-torsa] crl url http://4.4.4.133:447/security_rsa.crl

[Sysname-pki-domain-torsa] quit

3) Generate a local key pair using RSA.

[Sysname] rsa local-key-pair create

4) Apply for a certificate

# Retrieve CA certificate and download locally.

[Sysname] pki retrieval-certificate ca domain torsa

# Retrieve CRL and download locally.

[Sysname] pki retrieval-crl domain torsa

# Apply for a local certificate manually.

[Sysname] pki request-certificate domain torsa challenge-word

1.14.2 Access Control Policy of Certificate Attribute

I. Network requirements

l The client accesses the remote device (HTTPS Server) with HTTP Security (HTTPS) protocol.

l Make sure the authorized client logs in to the HTTPS server safely with SSL.

l Create an access control policy of certificate attributes for the HTTPS server to take control of the access right of the client.

II. Networking diagram

Figure 1-3 Networking diagram for access control policy of certificate attributes

III. Configuration procedure

& Note:

l For SSL configuration, refer to SSL-HTTPS Operation Manual.

l For HTTPS configuration, refer to SSL-HTTPS Operation Manual

1) On the HTTPS server, perform the following configuration:

# Configure the SSL policy used by the HTTPS server. The PKI domain to be referred must be already created.

<Sysname> system-view

[Sysname] ssl server-policy myssl

[Sysname-ssl-server-policy-myssl] pki-domain 1

[Sysname-ssl-server-policy-myssl] client-verify enable

[Sysname-ssl-server-policy-myssl] quit

2) Configure the certificate attribute group.

# Configure the certificate attribute group mygroup1 and create two attribute rules. The first rule defines that the DN of the subject name includes the string aabbcc, and the second rule defines that the IP address of the certificate issuer is 10.0.0.1.

[Sysname] pki certificate attribute-group mygroup1

[Sysname-pki-cert-attribute-group-mygroup1] attribute 1 subject-name dn ctn aabbcc

[Sysname-pki-cert-attribute-group-mygroup1] attribute 2 issuer-name ip equ 10.0.0.1

[Sysname-pki-cert-attribute-group-mygroup1] quit

# Configure the certificate attribute group mygroup2 and create two attribute rules. The first rule defines that the FQDN of the subject name does not include the string apple, and the second rule defines that the DN of the certificate issuer name includes the string aabbcc.

[Sysname] pki certificate attribute-group mygroup2

[Sysname-pki-cert-attribute-group-mygroup2] attribute 1 alt-subject-name fqdn nctn apple

[Sysname-pki-cert-attribute-group-mygroup2] attribute 2 issuer-name dn ctn aabbcc

[Sysname-pki-cert-attribute-group-mygroup2] quit

3) Configure the certificate access control policy.

# Configure the certificate access control policy myacp and create two ACL rules.

[Sysname] pki certificate access-control-policy myacp

[Sysname-pki-cert-acp-myacp] rule 1 deny mygroup1

[Sysname-pki-cert-acp-myacp] rule 2 permit mygroup2

[Sysname-pki-cert-acp-myacp] quit

4) Associate the HTTPS server to the corresponding policies, and start the HTTPS server.

# Configure the SSL policy for the HTTPS server as myssl.

[Sysname] ip https ssl-server-policy myssl

# Configure the certificate access control policy for the HTTPS server as myacp.

[Sysname] ip https certificate access-control-policy myacp

# Start the HTTPS server.

[Sysname] ip https enable

1.15 Troubleshooting

1.15.1 Failure to Retrieve a CA Certificate

If you fail to acquire a CA certificate, the reasons might come from:

1) Software problems

l No trusted CA is specified.

l Verify that the Simple Certificate Enrollment Protocol) SCEP is installed.

l The URL of the enrollment server used for certificate request through SCEP is not correct or not configured. You can check if the server is well connected by using the ping command.

l No RA is specified.

l System clock is not synchronized with CA.

2) Hardware problems

l Network connection faults, such as broken network cable and loose interface.

1.15.2 Failure to Request a Local Certificate

If you fail to request a local certificate when the router has finished the configuration of PKI domain parameters and entity DN, and has created a new RSA key pair, the reasons might come from:

1) Software problems

l No CA/RA certificate has been retrieved.

l The current key pair has had a certificate.

l No trusted CA is specified.

l Verify that the Simple Certificate Enrollment Protocol) SCEP is installed.

l The URL of the enrollment server used for the certificate request through SCEP is not correct or not configured. You can check if the server is well connected by using the ping command.

l No certificate authority is configured.

l The necessary attributes of entity DN are not configured. You can configure the relevant attributes by checking CA/RA authentication policy.

2) Hardware problems

Network connection faults, such as broken network cable and loose interface.

1.15.3 Failure to Retrieve a CRL

If you fail to retrieve a CRL, the reasons might come from:

1) Software problems

l No CA certificate exists when you try to retrieve a CRL.

l IP address of LDAP server is not configured.

l CRL distribution point location is not configured.

l LDAP server version is wrong.

2) Hardware problems

Network connection faults, such as broken network cable and loose interface.

H3C S5500-SI Series Ethernet Switches Operation Manual-Release 1205-(V1.03)

Chapter 1 PKI Configuration

1.1 Introduction to PKI

I. Digital certificate

II. Certificate revocation list

III. Lightweight directory access protocol server

1.1.3 System Architecture

I. Terminal entity

II. CA

III. Registration authority

IV. PKI repository

1.1.4 Applications

I. Virtual private network

II. Secure E-mail

III. Web security

1.2 Implementation of PKI in Devices

I. Applying for and revoking a certificate

II. Using a certificate

1.4 Configuring Entity Name Space

1.5 Creating a PKI Domain

1.7 Submitting a PKI Certificate Request

1.7.1 Submitting a Certificate Request Automatically

1.7.2 Submitting a Certificate Request Manually

1.8 Retrieving a Certificate Manually

1.9 Configuring PKI Certificate Validation

1.10 Destroying a Local RSA Key Pair

1.11 Deleting a Certificate

1.12 Configuring Access Control Policy of Certificate Attribute

1.13 Displaying and Maintaining PKI

1.14 Typical Configuration Examples

I. Network requirements

II. Network diagram

III. Configuration procedure

1.14.2 Access Control Policy of Certificate Attribute

I. Network requirements

II. Networking diagram

III. Configuration procedure

1.15 Troubleshooting

Cloud & AI

InterConnect

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Resources

Partner Business Management

Company Information

News & Events

Contact Us