Configuring PKI 1

Overview·· 1

PKI terms 1

PKI architecture· 2

PKI operation· 3

PKI applications 3

PKI configuration task list 3

Configuring an entity DN·· 4

Configuring a PKI domain· 5

Submitting a PKI certificate request 6

Submitting a certificate request in auto mode· 7

Submitting a certificate request in manual mode· 7

Retrieving a certificate manually· 8

Configuring PKI certificate verification· 9

Configuring PKI certificate verification with CRLchecking· 9

Configuring PKI certificate verification without CRL checking· 10

Destroying thelocal RSA or ECDSA key pair 10

Deleting a certificate· 10

Configuring an access control policy· 11

Displaying and maintaining PKI 11

PKI configuration examples 12

Troubleshooting PKI 12

Failed to retrieve a CA certificate· 12

Failed to request a local certificate· 12

Failed to retrieve CRLs 13

 

Overview

The PKI uses a general security infrastructure to provide 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 keyand a public key. The private key must be kept secret but 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 with PKI is how to manage the public keys. PKI employsthe 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 securityservices such as user authentication,data non-repudiation,data confidentiality, and data integrity.

H3C's PKI system provides certificate management forSSL.

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-TX.509. The most common standard is X.509 v3.

This documentinvolves local certificate and CA certificate. A local certificate is a digital certificate signed by a CA for an entity, anda CA certificateis the certificate of a CA.If multiple CAs are trusted by different users in a PKI system, the CAswillform aCA tree with the root CA at the top level.The root CAhas a CA certificatesigned by itself and each lower level CA has a CA certificate signed by the CA at the next higher level.

CRL

An existing certificate might need to be revoked when, for example, the username changes, the private key leaks, or the user stops the business. Revoking a certificate will 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 might publish multiple CRLs when the number of revoked certificates is so large that publishing them in a single CRL might 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 email. Becausedifferent CAs might use different methods to examinethe binding of a public key with an entity, make sure you understand the CA policy before selecting a trusted CA for certificate request.

PKI architecture

A PKI system consists of entities, a CA, a registration authority (RA) and a PKI repository, as shown in Figure 1.

Figure 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 ora common database.It stores and manages information like certificate requests, certificates, keys, CRLs and logs whenit provides 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.

PKI operation

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

2.        The RA reviews the identity of the entity and then sends the identity information and the public key with a digital signatureto 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 or other distribution points 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. The CA approves the request, updates the CRLs and publishes the CRLson the LDAP server or other distribution points.

PKI applications

The PKI technology can satisfy the security requirements of online transactions. As an infrastructure, PKI has a wide range of applications. The following lists some common application examples:

·          VPN—A VPN is a private data communication network built on the public communication infrastructure. A VPN can leverage network layer security protocols in conjunction with PKI-based encryption and digital signature technologies for confidentiality.

·          Secure email—Emails require confidentiality, integrity, authentication, and non-repudiation. PKI can address these needs. The secure email protocol that is developing rapidly is 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 of the communication parties can verifyeach other'sidentity through digital certificates.

PKI configuration task list

 

Task		Remarks
Configuring an entity DN		Required.
Configuring a PKI domain		Required.
Submitting a PKI certificate request	Submitting a certificate request in auto mode	Required. Use either approach.
	Submitting a certificate request in manual mode
Retrieving a certificate manually		Optional.
Configuring PKI certificate verification		Optional.
Destroying thelocal RSA or ECDSA key pair		Optional.
Deleting a certificate		Optional.
Configuring an access control policy		Optional.

 

Configuring an entity DN

A certificate is thebinding of a public key and the identity information of an entity, where the identity information is identified byan entity distinguished name (DN). A CA identifies a certificate applicant uniquely by entity DN.

An entity DN is defined by these parameters:

·          Common name of the entity.

·          Country code of the entity, a standard 2-character code. For example, CN represents China and US represents the United States.

·          FQDN of the entity, a unique identifier of an entity onthe 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.

·          IP address of the entity.

·          Locality where the entity resides.

·          Organization to which the entity belongs.

·          Unit of the entity in the organization.

·          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 requestsmight be rejected.

To configure an entity DN:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Create an entity and enter its view.	pki entityentity-name	No entity exists by default. You can create up to two entities on a device.
3.       Configure the common name for the entity.	common-namename	Optional. No common name is specified by default.
4.       Configure the country code for the entity.	country country-code-str	Optional. No country code is specified by default.
5.       Configure the FQDN for the entity.	fqdn name-str	Optional. No FQDN is specified by default.
6.       Configure the IP address for the entity.	ipip-address	Optional. No IP address is specified by default.
7.       Configure the locality for the entity.	locality locality-name	Optional. No locality is specified by default.
8.       Configure the organization name for the entity.	organization org-name	Optional. No organization is specified by default.
9.       Configure the unit name for the entity.	organization-unitorg-unit-name	Optional. No unit is specified by default.
10.    Configure the state or province for the entity.	state state-name	Optional. No state or province is specified by default.

 

	NOTE: The Windows 2000 CA server has some restrictions on the data length of a certificate request. If the entity DNin 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. The PKI domain configured on a device is invisible to the CA and other devices, and each PKI domain has its own parameters.

A PKI domain is defined bythese parameters:

·          Trusted CA—An entity requests a certificate from a trusted CA.

·          Entity—A certificate applicant uses an entity to provide its identity information to a CA.

·          RA—Generally, an independent RA is in charge of certificate requestmanagement. It receives the registration request from an entity, examinesits qualification, and determines whether to ask the CA to sign a digital certificate. The RA only examinesthe 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.H3C recommends you to deploy an independent RA.

·          URL of the registration server—An entity sends a certificate request to the registrationserver through SCEP, a dedicated protocol for an entity to communicate with a CA.

·          Polling interval and count—After an applicant makes a certificate request, the CA mightneed 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.

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

·          Fingerprint for root certificate verification—Afterreceiving 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.

To configure a PKI domain:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Create a PKI domain and enter its view.	pki domain domain-name	No PKI domain exists by default. You can configure up to 32 PKI domains on a device.
3.       Specify the trusted CA.	caidentifier name	No trusted CA is specified by default. The CA name is required only when you retrieve a CA certificate. It is not used for local certificate request.
4.       Specify the entity for certificate request.	certificate request entityentity-name	No entity is specified by default. The specified entity must exist.
5.       Specify the authority for certificate request.	certificate request from { ca | ra }	No authority is specified by default.
6.       Configure the URL ofthe server for certificate request.	certificate request url url-string	No URL is configured by default. The URL does not support domain name resolution.
7.       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.
8.       Specify the LDAP server.	ldap-serveripip-address [ portport-number ] [ versionversion-number ]	Optional. No LDP serveris specified by default.
9.       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 ofthe root certificate must be verified manually. No fingerprint is configured by default.
10.    Specify the certificate signature algorithm.	signature-algorithm { ecdsa | rsa }	Optional. RSA by default.

 

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 willbe the major components of the certificate. A certificate request can be submitted to a CA in offline mode or online mode. In offline mode, a certificate request is submitted to a CA byan "out-of-band" means such as phone, disk, or email.

Online certificate request falls into manual mode and auto mode.

Submitting a certificate request in auto mode

In auto mode, an entity automatically requests a certificate from the CA serverif it has no local certificatefor an application working with PKI. For example, when PKI certificate authentication is used, if no local certificate is available during IKE negotiation, the entity automatically requests one, and saves the local certificate after retrieving it from the CA. If the PKI domain has no CA certificate before the entity submits the certificate request, the entity automatically retrieves the CA certificate first.

If anautomatically requested certificate will expire or has expired, the entity does not initiate a re-request to the CA automatically, and the services using the certificate might be interrupted.

Toconfigure an entity to submit a certificate request in auto mode:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Enter PKI domain view.	pki domain domain-name	N/A
3.       Set the certificate request mode to auto.	certificate request mode auto [ key-length key-length| password { cipher | simple }password] *	Manual by default.

 

Submitting a certificate request in manual mode

In manual mode, you mustsubmit a local certificate request for an entity. Before the request, you must retrieve a CA certificate and generate a key pair for the PKI domain.

The CA certificate in the PKI domain is used to verify the authenticity and validity of a local certificate.

Generating a 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.The public key is transferred to the CA along with some other information.For more informationabout RSA and ECDSA key pair configuration, see"Managing public keys."

Configuration guidelines

·          If a PKI domain already has a local certificate, creating an RSA key pair might resultin inconsistency between the key pair and the certificate. To generate a new RSA key pair, delete the local certificate and then execute the public-key local create command. For more information about the public-key local create command, seeSecurity Command Reference.

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

·          If a PKI domain already has a local certificate, you cannot request another certificate for it. This helps avoid inconsistency between the certificate and the registration information resulting from configuration changes. Before requesting a new certificate, use the pki delete-certificate command to delete the existing local certificate and the CA certificate stored locally.

·          When it is impossible torequest a certificate from the CA through SCEP, you can print the request information or save the request information to a local file, and then send the printed information or saved file to the CA by an out-of-band means. To print the request information,use the pki request-certificate domain command with the pkcs10 keyword. To save the request information to a local file, use thepki request-certificate domain command with the pkcs10 filenamefilenameoption.

·          Make sure the clocks of the entity and the CA are synchronous. Otherwise, the validity period of the certificate will be abnormal.

Configuration procedure

To submit a certificate request in manual mode:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Enter PKI domain view.	pki domaindomain-name	N/A
3.       Set the certificate request mode to manual.	certificate request mode manual	Optional. Manual by default.
4.       Return to system view.	quit	N/A
5.       Retrieve a CA certificate manually.	See"Retrieving a certificate manually"	N/A
6.       Generate a local RSA or ECDSA key pair.	public-key local create { ecdsa | rsa }	No local RSA or ECDSA key pair exists by default.
7.       Submit a local certificate request manually.	pki request-certificate domain domain-name [ password ] [ pkcs10 [ filenamefilename ] ]	N/A This commandis not saved in the configuration file.

 

Retrieving a certificate manually

You can download CA certificates orlocal certificatesfrom the CA server and save themlocally. To do so, use either the offline mode orthe online mode. In offline mode, you must retrieve a certificate by an out-of-band means like FTP, disk, or email, and then import it into the local PKI system.

Certificate retrieval serves the following purposes:

·          Locally store the certificates associated with the local security domain for improved query efficiency and reduced query count.

·          Prepare for certificate verification.

Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration.

If a PKI domain already has a CA certificate, you cannot retrieve another CA certificate for it. This restriction helps avoid inconsistency between the certificate and registration information resulted from configuration changes. To retrieve a new CA certificate, use the pki delete-certificate command to delete the existing CA certificate and the local certificate first.

Be sure that the device system time falls in the validity period of the certificate so that the certificate is valid.

To retrieve a certificate manually:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Retrieve a certificate manually	·         In online mode: pki retrieval-certificate {ca | local } domaindomain-name ·         In offline mode: pki import-certificate{ ca | local}domaindomain-name{der|p12|pem}[filename filename ]	Use either command. The pki retrieval-certificate configuration is not saved in the configuration file.

 

Configuring PKI certificate verification

A certificate needs to be verified before being used. Verifying a certificate will check that the certificate is signed by the CAand that the certificate has neither expirednor been revoked.

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. In this case, be sure to retrieve the CA certificate and CRLs to the local device before the certificate verification. If you disable CRL checking, you only need to retrieve the CA certificate.

The CRL update period defines the interval at which the entity downloads CRLs from the CRL server. The CRL update period setting manually configured on the device is prior to that carried in the CRLs.

Configuring PKI certificate verification with CRLchecking

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Enter PKI domain view.	pki domain domain-name	N/A
3.       Specify the URL of the CRL distribution point.	crl url url-string	Optional. No CRL distribution pointURL is specified by default.
4.       Set the CRL update period.	crl update-periodhours	Optional. By default, the CRL update period depends on the next update field in the CRL file.
5.       Enable CRL checking.	crl checkenable	Optional. Enabled by default.
6.       Return to system view.	quit	N/A
7.       Retrieve the CA certificate.	See"Retrieving a certificate manually"	N/A
8.       Retrieve the CRLs.	pki retrieval-crl domain domain-name	This commandis not saved in the configuration file.
9.       Verify the validity of a certificate.	pki validate-certificate { ca | local } domaindomain-name	N/A

 

Configuring PKI certificate verification without CRL checking

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Enter PKI domain view.	pki domain domain-name	N/A
3.       Disable CRL checking.	crl checkdisable	Enabled by default.
4.       Return to system view.	quit	N/A
5.       Retrieve the CA certificate.	See"Retrieving a certificate manually"	N/A
6.       Verify the validity of the certificate.	pki validate-certificate { ca | local } domaindomain-name	N/A

 

Destroying thelocal 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.

To destroy the local RSA or ECDSA key pair:

 

Step	Command
1.       Enter system view.	system-view
2.       Destroy a local RSA or ECDSA key pair.	public-key local destroy { ecdsa |rsa }

 

For more informationabout the public-key local destroy command, seeSecurity 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.

To delete a certificate:

 

Step	Command
1.       Enter system view.	system-view
2.       Delete certificates.	pki delete-certificate { ca | local}domaindomain-name

 

Configuring an access control policy

By configuring acertificate attribute-based access control policy, you can further control access to the server, providing additional security for the server.

To configure a certificate attribute-based access control policy:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Create a certificate attribute group and enter its view.	pki certificate attribute-group group-name	No certificate attribute group exists by default.
3.       Configure anattribute rule for the certificate issuer name, certificate subject name,or alternative subject name.	attributeid { alt-subject-name { fqdn | ip } | { issuer-name | subject-name} { dn | fqdn | ip } } { ctn | equ | nctn | nequ} attribute-value	Optional. No restriction exists on the issuer name, certificate subject name and alternative subject name by default.
4.       Return to system view.	quit	N/A
5.       Create a certificate attribute-based access control policy and enter its view.	pki certificate access-control-policypolicy-name	No access control policy exists by default.
6.       Configure acertificate attribute-based access control rule.	rule [id ] { deny | permit } group-name	No access control rule exists by default. A certificate attribute group must exist to be associated with a rule.

 

Displaying and maintaining PKI

 

Task	Command	Remarks
Display the contents or request status of a certificate.	display pki certificate { {ca | local}domaindomain-name| request-status} [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display CRLs.	display pki crl domain domain-name [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display information aboutone or all certificate attribute groups.	display pki certificate attribute-group { group-name| all } [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display information aboutone or all certificate attribute-based access control policies.	display pki certificate access-control-policy { policy-name | all } [ | { begin | exclude | include } regular-expression ]	Available in any view.

 

PKI configuration examples

See "Configuring SSL" and Fundamentals Configuration Guide.

Troubleshooting PKI

Failed to retrieve a CA certificate

Symptom

Failed to retrieve a CA certificate.

Analysis

Possible reasons include:

·          The network connection is not proper. For example, the network cable might be damaged or loose.

·          No trusted CA is specified.

·          The URL of the registration server for certificate request is not correct or not configured.

·          No authority is specified for certificate request.

·          The system clock of the device is not synchronized with that of the CA.

Solution

1.        Make sure the network connection is physicallyproper.

2.        Check that the required commands are configured properly.

3.        Use the ping command to verify that the RA server is reachable.

4.        Specify the authority for certificate request.

5.        Synchronize the system clock of the device with that of the CA.

Failed to request a local certificate

Symptom

Failed to request a local certificate.

Analysis

Possible reasons include:

·          The network connection is not proper. For example, the network cable might be damaged or loose.

·          No CA certificate has been retrieved.

·          The current key pair has been bound to a certificate.

·          No trusted CA is specified.

·          The URL of the registration server for certificate request is not correct or not configured.

·          No authority is specified for certificate request.

·          Some required parameters of the entity DN are not configured.

Solution

1.        Make sure the network connection is physicallyproper.

2.        Retrieve a CA certificate.

3.        Regenerate a key pair.

4.        Specify a trusted CA.

5.        Use the ping command to verify that the RA server is reachable.

6.        Specify the authority for certificate request.

7.        Configure the required entity DN parameters.

Failed to retrieve CRLs

Symptom

Failed to retrieve CRLs.

Analysis

Possible reasons include:

·          The network connection is not proper. For example, the network cable might be damaged or loose.

·          No CA certificate has been retrieved before you try to retrieve CRLs.

·          The IP address of LDAP server is not configured.

·          The CRL distributionURL is not configured.

·          The LDAP server version is wrong.

·          The domain name of the CRL distribution point failed to be resolved.

Solution

1.        Make sure the network connection is physicallyproper.

2.        Retrieve a CA certificate.

3.        Specify the IP address of the LDAP server.

4.        Specify the CRL distributionURL.

5.        Re-configure the LDAP version.

6.        Configure the correct DNS server that can resolve the domain name of the CRL distribution point.