Login
- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 06-PKI Configuration | 140.8 KB |
Submitting a PKI Certificate Request
Submitting a Certificate Request in Auto Mode
Submitting a Certificate Request in Manual Mode
Retrieving a Certificate Manually
Configuring PKI Certificate Verification
Destroying a Local RSA or ECDSA Key Pair
Configuring an Access Control Policy
Displaying and Maintaining PKI
Failed to Retrieve a CA Certificate
Failed to Request a Local Certificate
l Support of the H3C WA series WLAN access points (APs) for features may vary by AP model. For more information, see Feature Matrix.
l The interface types and the number of interfaces vary by AP model.
l The term AP in this document refers to common APs, wireless bridges, and mesh APs.
l The models listed in this document are not applicable to all regions. Please consult your local sales office for the models applicable to your region.
1 PKI Configuration
This chapter includes these sections:
l Displaying and Maintaining PKI
Introduction to PKI
This section covers these topics:
PKI Overview
The Public Key Infrastructure (PKI) is a general security infrastructure for providing information security through public key technologies.
PKI, also called asymmetric key infrastructure, uses a key pair to encrypt and decrypt the data. The key pair consists of a private key and a public key. The private key must be kept secret while the public key needs to be distributed. Data encrypted by one of the two keys can only be decrypted by the other.
A key problem of PKI is how to manage the public keys. Currently, PKI employs the digital certificate mechanism to solve this problem. The digital certificate mechanism binds public keys to their owners, helping distribute public keys in large networks securely.
With digital certificates, the PKI system provides network communication and e-commerce with security services such as user authentication, data non-repudiation, data confidentiality, and data integrity.
Currently, H3C's PKI system provides certificate management for IP Security (IPsec) and Secure Sockets Layer (SSL).
PKI Terms
Digital certificate
A digital certificate is a file signed by a certificate authority (CA) for an entity. It includes mainly the identity information of the entity, the public key of the entity, the name and signature of the CA, and the validity period of the certificate, where the signature of the CA ensures the validity and authority of the certificate. A digital certificate must comply with the international standard of ITU-T X.509. Currently, the most common standard is X.509 v3.
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 is the certificate of a CA. If multiple CAs are trusted by different users in a PKI system, the CAs will form a CA tree with the root CA at the top level. The root CA has a CA certificate signed by itself while each lower level CA has a CA certificate signed by the CA at the next higher level.
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 through certificate revocation lists (CRLs). Whenever a certificate is revoked, the CA publishes one or more CRLs to show all certificates that have been revoked. The CRLs contain the serial numbers of all revoked certificates and provide 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, and it uses CRL distribution points to indicate the URLs of these CRLs.
CA policy
A CA policy is a set of criteria that a CA follows in processing certificate requests, issuing and revoking certificates, and publishing CRLs. Usually, a CA advertises its policy in the form of certification practice statement (CPS). A CA policy can be acquired through out-of-band means such as phone, disk, and e-mail. As 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.
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
Entity
An entity is an end user of PKI products or services, such as a person, an organization, a device like a router or a switch, or a process running on a computer.
CA
A CA is a trusted authority responsible for issuing and managing digital certificates. A CA issues certificates, specifies the validity periods of certificates, and revokes certificates as needed by publishing CRLs.
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.
PKI repository
A PKI repository can be a Lightweight Directory Access Protocol (LDAP) server or a common database. It 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.
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.
VPN
A virtual private network (VPN) is a private data communication network built on 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.
Secure E-mail
E-mails 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 with signature.
Web security
For Web security, two peers can establish an SSL connection first for transparent and secure communications at the application layer. With PKI, SSL enables encrypted communications between a browser and a server. Both the communication parties can verify the identity of each other through digital certificates.
Operation of PKI
In a PKI-enabled network, an entity can request a local certificate from the CA and the AP can check the validity of certificates. Here is how it works:
1) An entity submits a certificate request to the RA.
2) The 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 verifies 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 publishes the CRLs on the LDAP server.
PKI Configuration Task List
Complete the following tasks to configure PKI:
|
Remarks |
||
|
Required |
||
|
Required |
||
|
Required Use either approach |
||
|
Optional |
||
|
Optional |
||
|
Optional |
||
|
Optional |
||
|
Optional |
||
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 an AP.
l The 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 will not respond to the certificate request.
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 like IKE and SSL, 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 registration server
An entity sends a certificate request to the registration 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 verification
Upon receiving the root certificate of the CA, an entity needs to verify the fingerprint of the root certificate, namely, the hash value of the root certificate content. This hash value is unique to every certificate. If the fingerprint of the root certificate does not match the one configured for the PKI domain, the entity will reject the root certificate.
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 attempt limit 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 verification |
root-certificate fingerprint { md5 | sha1 } string |
Required when the certificate request mode is auto and optional when the certificate request mode is manual. In the latter case, if you do not configure this command, the fingerprint of the root certificate must be verified manually. No fingerprint is configured by default. |
|
Specify the certificate signature algorithm |
signature-algorithm { ecdsa | rsa } |
Optional RSA 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.
l Currently, the URL of the server for certificate request does not support domain name resolving.
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. 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.
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 |
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 more information about RSA and ECDSA key pair configuration, see Public Key in the Security Configuration Guide.
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 |
Required |
|
|
Generate a local RSA or ECDSA key pair |
public-key local create { ecdsa | rsa } |
Required No local RSA or ECDSA key pair exists by default. |
|
Submit a local certificate request manually |
pki request-certificate domain domain-name [ password ] [ pkcs10 [ filename filename ] ] |
Required |
l If a PKI domain already has a local certificate, creating an RSA key pair will result in inconsistency between the key pair and the certificate. To generate a new RSA key pair, delete the local certificate and then issue the public-key local create command. For information about the public-key local create command, see Public Key in the Security Command Reference.
l A newly created key pair will overwrite the existing one. If you perform the public-key local create command in the presence of a local RSA or ECDSA 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 registration 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 the entity and the CA are synchronous. Otherwise, the validity period of the certificate will be abnormal.
l The pki request-certificate domain configuration will not be saved in the configuration file.
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 verification.
Before retrieving a local certificate in online mode, 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 ] |
||
l If a PKI domain already has a CA certificate, you cannot retrieve another CA certificate for it. This is in order to avoid inconsistency between the certificate and registration 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.
Configuring PKI Certificate Verification
A certificate needs to be verified before being used. Verifying a certificate is to check that the certificate is signed by the CA and that the certificate has neither expired nor been revoked.
Before verifying a certificate, you need to retrieve the CA certificate.
You can specify whether CRL checking is required in certificate verification. If you enable CRL checking, CRLs will be used in verification of a certificate.
Configuring CRL-checking-enabled PKI certificate verification
Follow these steps to configure CRL-checking-enabled PKI certificate verification:
|
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 |
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 |
Configuring CRL-checking-disabled PKI certificate verification
Follow these steps to configure CRL-checking-disabled PKI certificate verification:
|
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 |
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.
l Currently, the URL of the CRL distribution point does not support domain name resolving.
Destroying a Local RSA or ECDSA Key Pair
A certificate has a lifetime, which is determined by the CA. When the private key leaks or the certificate is about to expire, you can destroy the old RSA or ECDSA key pair and then create a pair to request a new certificate.
Follow these steps to destroy a local RSA key pair:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Destroy a local RSA or ECDSA key pair |
public-key local destroy { ecdsa | rsa } |
Required |
For more information about the public-key local destroy command, see Public Key in the Security Command Reference.
Deleting a Certificate
When a certificate requested manually is about to expire or you want to request a new certificate, you can delete the current local certificate or CA certificate.
Follow these steps to delete a certificate:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Delete certificates |
pki delete-certificate { ca | local } domain domain-name |
Required |
Configuring an Access Control Policy
By configuring a certificate attribute-based access control policy, you can further control access to the server, providing additional security for the server.
Follow these steps to configure a certificate attribute-based access control policy:
|
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 exists by default. |
|
Configure an attribute rule for the certificate issuer name, certificate subject name, or alternative subject name |
attribute id { alt-subject-name { fqdn | ip } | { issuer-name | subject-name } { dn | fqdn | ip } } { ctn | equ | nctn | nequ } attribute-value |
Optional There is no restriction on the issuer name, certificate subject name and alternative subject name by default. |
|
Return to system view |
quit |
— |
|
Create a certificate attribute-based access control policy and enter its view |
pki certificate access-control-policy policy-name |
Required No access control policy exists by default. |
|
Configure a certificate attribute-based access control rule |
rule [ id ] { deny | permit } group-name |
Required No access control rule exists by default. |
A certificate attribute group must exist to be associated with a rule.
Displaying and Maintaining PKI
|
To do… |
Use the command… |
Remarks |
|
Display the contents or request status of a certificate |
display pki certificate { { ca | local } domain domain-name | request-status } |
Available in any view |
|
Display CRLs |
display pki crl domain domain-name |
Available in any view |
|
Display information about one or all certificate attribute groups |
display pki certificate attribute-group { group-name | all } |
Available in any view |
|
Display information about one or all certificate attribute-based access control policies |
display pki certificate access-control-policy { policy-name | all } |
Available in any view |
PKI Configuration Examples
For PKI configuration examples, see:
l SSH2.0 in the Security Configuration Guide
l HTTP in the Fundamentals Configuration Guide
Troubleshooting PKI
Failed to Retrieve a CA Certificate
Symptom
Failed to retrieve a CA certificate.
Analysis
Possible reasons include these:
l The network connection is not proper. For example, the network cable may be damaged or loose.
l No trusted CA is specified.
l The URL of the registration server for certificate request is not correct or not configured.
l No authority is specified for certificate request.
l The system clock of the AP is not synchronized with that of the CA.
Solution
l Make sure that the network connection is physically proper.
l Check that the required commands are configured properly.
l Use the ping command to check that the RA server is reachable.
l Specify the authority for certificate request.
l Synchronize the system clock of the AP with that of the CA.
Failed to Request a Local Certificate
Symptom
Failed to request a local certificate.
Analysis
Possible reasons include these:
l The network connection is not proper. For example, the network cable may be damaged or loose.
l No CA certificate has been retrieved.
l The current key pair has been bound to a certificate.
l No trusted CA is specified.
l The URL of the registration server for certificate request is not correct or not configured.
l No authority is specified for certificate request.
l Some required parameters of the entity DN are not configured.
Solution
l Make sure that the network connection is physically proper.
l Retrieve a CA certificate.
l Regenerate a key pair.
l Specify a trusted CA.
l Use the ping command to check that the RA server is reachable.
l Specify the authority for certificate request.
l Configure the required entity DN parameters.
Failed to Retrieve CRLs
Symptom
Failed to retrieve CRLs.
Analysis
Possible reasons include these:
l The network connection is not proper. For example, the network cable may be damaged or loose.
l No CA certificate has been retrieved before you try to retrieve CRLs.
l The IP address of LDAP server is not configured.
l The CRL distribution URL is not configured.
l The LDAP server version is wrong.
Solution
l Make sure that the network connection is physically proper.
l Retrieve a CA certificate.
l Specify the IP address of the LDAP server.
l Specify the CRL distribution URL.
l Re-configure the LDAP version.
