PKI uses digital certificates to distribute and employ public keys, and provides network communication and e-commerce with security services such as user authentication, data confidentiality, and data integrity. For more information about public keys, see "Managing public keys."

PKI terminology

Digital certificate

A digital certificate is an electronic document signed by a CA that binds a public key with the identity of its owner.

A digital certificate includes the following information:

· Issuer name (name of the CA that issued the certificate).

· Subject name (name of the individual or group to which the certificate is issued).

· Identity information of the subject.

· Subject's public key.

· Signature of the CA.

· Validity period.

A digital certificate must comply with the international standards of ITU-T X.509, of which X.509 v3 is the most commonly used.

This chapter covers the following types of certificates:

· CA certificate—Certificate of a CA. Multiple CAs in a PKI system form a CA tree, with the root CA at the top. The root CA generates a self-signed certificate, and each lower level CA holds a CA certificate issued by the CA immediately above it. The chain of these certificates forms a chain of trust.

· Registration authority (RA) certificate—Certificate issued by a CA to an RA. RAs act as proxies for CAs to process enrollment requests in a PKI system.

· Local certificate—Digital certificate issued by a CA to a local PKI entity, which contains the entity's public key.

· Peer certificate—CA-signed digital certificate of a peer, which contains the peer's public key.

Fingerprint of root CA certificate

Each root CA certificate has a unique fingerprint, which is the hash value of the certificate content. The fingerprint of a root CA certificate can be used to authenticate the validity of the root CA.

Certificate revocation list

A certificate revocation list (CRL) is a list of serial numbers for certificates that have been revoked. A CRL is created and signed by the CA that originally issued the certificates.

The CA publishes CRLs periodically to revoke certificates. Entities that are associated with the revoked certificates should not be trusted.

The CA must revoke a certificate when any of the following conditions occurs:

· The certificate subject name is changed.

· The private key is compromised.

· The association between the subject and CA is changed. For example, when an employee terminates employment with an organization.

CA policy

A CA policy is a set of criteria that a CA follows to process certificate requests, to issue and revoke certificates, and to publish CRLs. Typically, a CA advertises its policy in a certification practice statement (CPS). You can obtain a CA policy through out-of-band means such as phone, disk, and email. Make sure you understand the CA policy before you select a trusted CA for certificate request because different CAs might use different policies.

PKI architecture

A PKI system consists of PKI entities, CAs, RAs and a certificate/CRL repository, as shown in Figure 1.

Figure 1 PKI architecture

PKI entity

A PKI entity is an end user using PKI certificates. A PKI entity can be an operator, an organization, a device like a router or a switch, or a process running on a computer. PKI entities use SCEP to communicate with the CA or RA.

CA

A certification authority (CA) grants and manages certificates. It issues certificates, defines the certificate validity periods, and revokes certificates by publishing CRLs.

RA

A registration authority (RA) offloads the CA by processing certificate enrollment requests. The RA accepts certificate requests, verifies user identity, and determines whether to ask the CA to issue certificates.

The RA is optional in a PKI system. In cases when there is security concern over exposing the CA to direct network access, it is advisable to delegate some of the tasks to an RA. Then, the CA can concentrate on its primary tasks of signing certificates and CRLs.

Certificate/CRL repository

A certificate/CRL repository is a certificate distribution point that stores certificates and CRLs, and distributes these certificates and CRLs to PKI entities. It also provides the query function. A PKI repository can be a directory server using the LDAP or HTTP protocol, of which LDAP is commonly used.

Retrieval, usage, and maintenance of a digital certificate

The following workflow describes the retrieval, usage, and maintenance of a digital certificate. This example uses a CA which has an RA to process certificate enrollment requests.

1. A PKI entity generates an asymmetric key pair and submits a certificate request to the RA.

The certificate request contains the public key and its identity information.

2. The RA verifies the identity of the entity and sends a digital signature containing the identity information and the public key to the CA.

3. The CA verifies the digital signature, approves the request, and issues a certificate.

4. After receiving the certificate from the CA, the RA sends the certificate to the certificate repository and notifies the PKI entity that the certificate has been issued.

5. The PKI entity obtains the certificate from the certificate repository.

6. To establish a secure connection for communication, two PKI entities exchange local certificates to authenticate each other. The connection can be established only if both entities verify that the peer's certificate is valid.

7. You can remove the local certificate of a PKI entity and request a new one when any of the following conditions occur:

¡ The local certificate is about to expire.

¡ The certificate's private key is compromised.

PKI applications

The PKI technology can meet security requirements of online transactions. As an infrastructure, PKI has a wide range of applications. The PKI system of H3C can provide certificate management for IPsec and SSL.

The following are some application examples.

VPN

A VPN is a private data communication network built on the public communication infrastructure. A VPN can use network layer security protocols (for example, IPsec) in conjunction with PKI-based encryption and digital signature technologies for confidentiality.

Secure emails

PKI can address the email requirements for confidentiality, integrity, authentication, and non-repudiation. A common secure email protocol is Secure/Multipurpose Internet Mail Extensions (S/MIME), which is based on PKI and allows for transfer of encrypted mails with signature.

Web security

PKI can be used in the SSL handshake phase to verify the identities of the communicating parties by digital certificates.

PKI task s at a glance

To configure PKI, perform the following tasks:

1. Configuring a PKI entity

2. Configuring a PKI domain

3. (Optional.) Specifying the storage path for certificates and CRLs

4. Requesting a certificate

Choose one of the following tasks:

¡ Enabling the automatic online certificate request mode

¡ Manually submitting an online certificate request

¡ Manually submitting a certificate request in offline mode

5. (Optional.) Aborting a certificate request

6. (Optional.) Obtaining certificates

You can obtain the CA certificate, local certificates, and peer certificates related to a PKI domain from a CA and save them locally for higher lookup efficiency.

7. (Optional.) Verifying PKI certificates

8. (Optional.) Exporting certificates

9. (Optional.) Removing a certificate

10. (Optional.) Configuring a certificate-based access control policy

Certificate-based access control policies allow you to authorize access to a device (for example, an HTTPS server) based on the attributes of an authenticated client's certificate.

Configuring a PKI entity

About PKI entities

A certificate applicant uses an entity to provide its identity information to a CA. A valid PKI entity must include one or more of following identity categories:

· Distinguished name (DN) of the entity, which further includes the common name, country code, locality, organization, unit in the organization, and state. If you configure the DN for an entity, a common name is required.

· FQDN of the entity.

· IP address of the entity.

Restrictions and guidelines for PKI entity configuration

Follow these restrictions and guidelines when you configure a PKI entity:

· Whether the identity categories are required or optional depends on the CA policy. Follow the CA policy to configure the entity settings. For example, if the CA policy requires the entity DN, but you configure only the IP address, the CA rejects the certificate request from the entity.

· The SCEP add-on on the Windows 2000 CA server has restrictions on the data length of a certificate request. If a request from a PKI entity exceeds the data length limit, the CA server does not respond to the certificate request. In this case, you can use an out-of-band means to submit the request. Other types of CA servers, such as RSA servers and OpenCA servers, do not have such restrictions.

PKI entity tasks at a glance

To configure a PKI entity, perform the following tasks:

1. Configuring the DN for the PKI entity

2. Configuring the FQDN for the PKI entity

3. Configuring the IP address for the PKI entity

Configuring the DN for the PKI entity

Restrictions and guidelines for configuring the DN for the PKI entity

You can configure the individual attributes used to construct the DN string for the PKI entity, or directly configure the full DN string by using the subject-dn command.

If the subject-dn command is configured, the individual DN attributes configured by using the common-name, country, locality, organization, organization-unit, and state commands do not take effect.

Configuring the individual DN attributes

1. Enter system view.

system-view

2. Create a PKI entity and enter its view.

pki entity entity-name

3. Set a common name for the entity.

common-name common-name-sting

By default, the common name is not set.

4. Set the country code of the entity.

country country-code-string

By default, the country code is not set.

5. Set the locality of the entity.

locality locality-name

By default, the locality is not set.

6. Set the organization of the entity.

organization org-name

By default, the organization is not set.

7. Set the unit of the entity in the organization.

organization-unit org-unit-name

By default, the unit is not set.

8. Set the state where the entity resides.

state state-name

By default, the state is not set.

Configuring the full DN string

1. Enter system view.

system-view

2. Create a PKI entity and enter its view.

pki entity entity-name

3. Configure the full subject DN string.

subject-dn dn-string

By default, the PKI entity DN is not configured.

Configuring the FQDN for the PKI entity

1. Enter system view.

system-view

2. Create a PKI entity and enter its view.

pki entity entity-name

3. Configure the FQDN for the PKI entity.

fqdn fqdn-name-string

By default, the FQDN is not configured.

Configuring the IP address for the PKI entity

1. Enter system view.

system-view

2. Create a PKI entity and enter its view.

pki entity entity-name

3. Configure the IP address for the PKI entity.

ip { ip-address | interface interface-type interface-number }

By default, the IP address is not configured.

Configuring a PKI domain

About PKI domains

A PKI domain contains enrollment information for a PKI entity. It is locally significant and is intended only for use by other applications like IKE and SSL.

PKI domain tasks at a glance

To configure a PKI domain, perform the following tasks:

1. Creating a PKI domain

2. Specifying the trusted CA

3. Specifying the PKI entity name

4. Specifying the certificate request reception authority

5. Specifying the certificate request URL

6. (Optional.) Setting the SCEP polling interval and maximum polling attempts

7. Specifying the LDAP server

This task is required when either of the following conditions is met:

¡ The device must obtain certificates from the CA by using the LDAP protocol.

¡ An LDAP URL which does not contain the host name of the LDAP server is specified as the CRL repository URL.

8. Specifying the fingerprint for root CA certificate verification

This step is required if the auto certificate request mode is configured in the PKI domain.

If the manual certificate request mode is configured, you can skip this step and manually verify the fingerprint displayed during verification of the root CA certificate.

9. Specifying the key pair for certificate request

10. (Optional.) Specifying the intended purpose for the certificate

11. (Optional.) Specifying the source IP address for PKI protocol packets

12. (Optional.) Specifying the encryption algorithm for certificate files in PKCS#7 format

Creating a PKI domain

1. Enter system view.

system-view

2. Create a PKI domain and enter its view.

pki domain domain-name

Specifying the trusted CA

root-certificate fingerprint { md5 | sha1 } string

By default, no fingerprint is configured.

Specifying the key pair for certificate request

About this task

You can specify any of the following types of key pairs for certificate request in a PKI domain:

· DSA.

· ECDSA.

· RSA.

The private key of the key pair is kept secret. The public key of the key pair will be sent together with other information in a certificate request to the CA, which signs the request data and issues the certificate.

For more information about DSA, ECDSA, and RSA key pairs, see "Managing public keys."

Restrictions and guidelines

You can specify a nonexistent key pair for certificate request. The PKI entity automatically creates the key pair before submitting a certificate request.

Procedure

1. Enter system view.

system-view

2. Enter PKI domain view.

pki domain domain-name

3. Specify the key pair for certificate request.

¡ Specify an RSA key pair.

public-key rsa { { encryption name encryption-key-name [ length key-length ] | signature name signature-key-name [ length key-length ] } * | general name key-name [ length key-length ] }

¡ Specify an ECDSA key pair.

public-key ecdsa name key-name [ secp192r1 | secp256r1 | secp384r1 | secp521r1 ]

¡ Specify a DSA key pair.

public-key dsa name key-name [ length key-length ]

By default, no key pair is specified.

Specifying the intended purpose for the certificate

About this task

An issued certificate contains the extensions which restrict the usage of the certificate to specific purposes. You can specify the intended purposes for a certificate, which will be included in the certificate request sent to the CA. However, the actual extensions contained in an issued certificate depend on the CA policy, and they might be different from those specified in the PKI domain. Whether an application (such as IKE and SSL) will use the certificate during authentication depends on the application's policy.

Supported certificate extensions include:

· ike—Certificates carrying this extension can be used by IKE peers.

· ssl-client—Certificates carrying this extension can be used by SSL clients.

· ssl-server—Certificates carrying this extension can be used by SSL servers.

Procedure

1. Enter system view.

system-view

2. Enter PKI domain view.

pki domain domain-name

3. Specify the intended use for the certificate.

usage { ike | ssl-client | ssl-server } *

By default, the certificate can be used by all supported applications, including IKE, SSL client, and SSL server.

Specifying the source IP address for PKI protocol packets

About this task

This task is required if the CA policy requires that the CA server accept certificate requests from a specific IP address or subnet.

Procedure

1. Enter system view.

system-view

2. Enter PKI domain view.

pki domain domain-name

3. Specify a source IP address for the PKI protocol packets.

IPv4:

source ip { ip-address | interface interface-type interface-number }

IPv6:

source ipv6 { ipv6-address | interface interface-type interface-number }

By default, the source IP address of PKI protocol packets is the IP address of their outgoing interface.

Specifying the encryption algorithm for certificate files in PKCS#7 format

About this task

During online certificate request, the device uses the specified encryption algorithm to encrypt the certificate signing request in PKCS#7 format before sending the request to the CA. After obtaining the certificate issued by the CA, the device uses the encryption algorithm to decrypt the certificate file in PKCS#7 format. Make sure the specified encryption algorithm is supported on the CA server.

Procedure

1. Enter system view.

system-view

2. Enter PKI domain view.

pki domain domain-name

3. Specify the encryption algorithm for certificate files in PKCS#7 format.

pkcs7-encryption-algorithm { 3des-cbc | aes-cbc-128 | des-cbc }

By default, the DES-CBC encryption algorithm is used.

Specifying the storage path for certificates and CRLs

About this task

The device has a default storage path for certificates and CRLs. You can change the storage path and specify different paths for the certificates and CRLs.

After you change the storage path for certificates or CRLs, the certificate files and CRL files in the original path are moved to the new path. Certificate files use the .cer or .p12 file extension and CRL files use the .crl file extension.

Restrictions and guidelines

If you change the storage path, save the configuration before you reboot or shut down the device to avoid loss of certificates or CRLs.

Procedure

1. Enter system view.

system-view

2. Specify the storage path for certificates and CRLs.

pki storage { certificates | crls } dir-path

By default, the device stores certificates and CRLs in the PKI directory on the storage media of the device.

Requesting a certificate

About certificate request configuration

To request a certificate, a PKI entity must provide its identity information and public key to a CA.

A certificate request can be submitted to a CA in offline or online mode.

· Offline mode—A certificate request is submitted by using an out-of-band method, such as phone, disk, or email.

· Online mode—A certificate request can be automatically or manually submitted to a CA through the Simple Certificate Enrollment Protocol (SCEP).

Restrictions and guidelines for certificate request configuration

When you request a local certificate in a PKI domain, follow these restrictions and guidelines:

· To prevent an existing local certificate from becoming invalid, do not perform the following tasks:

¡ Create a key pair with the same name as the key pair contained in the certificate.

To create a key pair, use the public-key local create command.

¡ Destroy the key pair contained in the certificate.

To destroy a key pair, use the public-key local destroy command.

For more information about the public-key local create and public-key local destroy commands, see public key management commands in Security Command Reference.

· To manually request a new certificate in a PKI domain that already has a local certificate, use the following procedure:

a. Use the pki delete-certificate command to delete the existing local certificate.

b. Use the public-key local create command to generate a new key pair.

c. Manually submit a certificate request.

· A PKI domain can have local certificates using only one type of cryptographic algorithms (DSA, ECDSA, or RSA). If DSA or ECDSA is used, a PKI domain can have only one local certificate. If RSA is used, a PKI domain can have one local certificate for signature, and one local certificate for encryption.

Prerequisites for certificate request configuration

Make sure the device is time synchronized with the CA server. If the device is not time synchronized with the CA server, the certificate request might fail because the certificate might be considered to be outside of the validity period. For information about configuring the system time, see system management in System Management Configuration Guide.

Enabling the automatic online certificate request mode

About this task

In auto request mode, a PKI entity with no local certificates automatically submits a certificate request to the CA when an application works with the PKI entity. For example, when IKE negotiation uses a digital signature for identity authentication, but no local certificate is available, the entity automatically submits a certificate request. It saves the certificate locally after obtaining the certificate from the CA.

A CA certificate must be present before you request a local certificate. If no CA certificate exists in the PKI domain, the PKI entity automatically obtains a CA certificate before sending a certificate request.

Certificate auto-renewal enables the system to automatically request a new certificate the specified number of days before the old certificate expires. The old certificate is replaced immediately when the new certificate is received.

Restrictions and guidelines

In auto request mode, the device does not automatically request a new certificate if the current certificate is about to expire or has expired, which might cause service interruptions.

To avoid service interruptions caused by certificate expiration, specify the renew-before-expire days option to enable certificate auto-renewal in auto certificate request mode.

Some CAs require a new PKI entity common name for certificate auto-renewal to work. Specify the automatic-append common-name keyword to ensure successful certificate auto-renewal.

Procedure

1. Enter system view.

system-view

2. Enter PKI domain view.

pki domain domain-name

3. Enable the automatic online certificate request mode.

certificate request mode auto [ password { cipher | simple } string | renew-before-expire days [ reuse-public-key ] [ automatic-append common-name ] ] *

By default, the manual request mode applies.

If the CA policy requires a password for certificate revocation, specify the password in this command.

Manually submitting an online certificate request

About this task

In manual request mode, you must execute the pki request-certificate domain command to request a local certificate in a PKI domain. The certificate will be saved in the domain after it is obtained from the CA.

Procedure

1. Enter system view.

system-view

2. Enter PKI domain view.

pki domain domain-name

3. Set the certificate request mode to manual.

certificate request mode manual

By default, the manual request mode applies.

4. Return to system view.

quit

5. Obtain a CA certificate.

See "Obtaining certificates."

This step is required if the PKI domain does not have a CA certificate. The CA certificate is used to verify the authenticity and validity of the obtained local certificate.

6. Manually submit an SCEP certificate request.

pki request-certificate domain domain-name [ password password ]

This command is not saved in the configuration file.

If the CA policy requires a password for certificate revocation, specify the password in this command.

Manually submitting a certificate request in offline mode

About this task

Use this method if the CA does not support SCEP or if a network connection between the device and CA is not possible.

Procedure

1. Enter system view.

system-view

2. Enter PKI domain view.

pki domain domain-name

3. Set the certificate request mode to manual.

certificate request mode manual

By default, the manual request mode applies.

4. Return to system view.

quit

5. Obtain the CA certificate.

See "Obtaining certificates."

This step is required if the PKI domain does not have a CA certificate. The CA certificate is used to verify the authenticity and validity of the obtained local certificate.

6. Print the certificate request in PKCS10 format on the terminal or save the certificate request to a PKCS10 file.

pki request-certificate domain domain-name pkcs10 [ filename filename ]

This command is not saved in the configuration file.

7. Transfer certificate request information to the CA by using an out-of-band method.

8. Transfer the issued local certificate from the CA to the local device by using an out-of-band method.

9. Import the local certificate to the PKI domain.

pki import domain domain-name { der local filename filename | p12 local filename filename | pem local } [ filename filename ] }

Aborting a certificate request

About this task

Before the CA issues a certificate, you can abort a certificate request and change its parameters, such as the common name, country code, or FQDN. You can use the display pki certificate request-status command to display the status of a certificate request.

Alternatively, you also can remove a PKI domain to abort the associated certificate request.

Procedure

1. Enter system view.

system-view

2. Abort a certificate request.

pki abort-certificate-request domain domain-name

This command is not saved in the configuration file.

Obtaining certificates

About this task

You can obtain the CA certificate, local certificates, and peer certificates related to a PKI domain from a CA and save them locally for higher lookup efficiency. To do so, use either the offline mode or the online mode:

· In offline mode, obtain the certificates by an out-of-band means like FTP, disk, or email, and then import them locally. Use this mode when the CRL repository is not specified, the CA server does not support SCEP, or the CA server generates the key pair for the certificates.

· In online mode, you can obtain the CA certificate through SCEP and obtain local certificates or peer certificates through LDAP.

Restrictions and guidelines

Follow these restrictions and guidelines when obtain certificates from a CA

· If a CA certificate already exists locally, you cannot obtain it again in online mode. If you want to obtain a new CA certificate, use the pki delete-certificate command to delete the existing CA certificate and local certificates first.

· If local or peer certificates already exist, you can obtain new local or peer certificates to overwrite the existing ones. If RSA is used, a PKI domain can have two local certificates, one for signature and the other for encryption.

· If CRL checking is enabled, obtaining a certificate triggers CRL checking. If the certificate to be obtained has been revoked, the certificate cannot be obtained.

· The device compares the validity period of a certificate with the local system time to determine whether the certificate is valid. Make sure the system time of the device is synchronized with the CA server.

Prerequisites

· Before you obtain local or peer certificates in online mode, make sure an LDAP server is correctly configured in the PKI domain.

· Before you import certificates in offline mode, complete the following tasks:

¡ Use FTP or TFTP to upload the certificate files to the storage media of the device.

If FTP or TFTP is not available, display and copy the contents of a certificate to a file on the device. Make sure the certificate is in PEM format because only certificates in PEM format can be imported.

¡ Before you import a local certificate or peer certificate, obtain the CA certificate chain that signs the certificate.

This step is required only if the CA certificate chain is neither available in the PKI domain nor contained in the certificate to be imported.

¡ Before you import a local certificate that contains an encrypted key pair, contact the CA administrator to obtain the password required for importing the certificate.

Procedure

1. Enter system view.

system-view

2. Obtain certificates.

¡ Import certificates in offline mode.

pki import domain domain-name { der { ca | local | peer } filename filename | p12 local filename filename | pem { ca | local | peer } [ filename filename ] }

¡ Obtain certificates in online mode.

pki retrieve-certificate domain domain-name { ca | local | peer entity-name }

This command is not saved in the configuration file.

Verifying PKI certificates

About certification verification

A certificate is automatically verified when it is requested, obtained, or used by an application. If the certificate expires, if it is not issued by a trusted CA, or if it is revoked, the certificate cannot be used You can also manually verify a certificate.

You can enable or disable CRL checking in a PKI domain. CRL checking checks whether a certificate is in the CRL. If it is, the certificate has been revoked and its home entity is not trusted.

To use CRL checking, a CRL must be obtained from a CRL repository. The device selects a CRL repository in the following order:

1. CRL repository specified in the PKI domain by using the crl url command.

2. CRL repository in the certificate that is being verified.

3. CRL repository in the CA certificate or CRL repository in the upper-level CA certificate if the certificate being verified is a CA certificate

If no CRL repository is found after the selection process, the device obtains the CRL through SCEP. In this scenario, the CA certificate and the local certificates must have been obtained.

A certificate fails CRL checking in the following situations:

· A CRL cannot be obtained during CRL checking of the certificate.

· CRL checking verifies that the certificate has been revoked.

Restrictions and guidelines for certificate verification

When verifying the CA certificate of a PKI domain, the system needs to verify all the certificates in the CA certificate chain. To ensure a successful certificate verification process, the device must have all the PKI domains to which the CA certificates in the certificate chain belong.

The system verifies the CA certificates in the CA certificate chain as follows:

1. Identifies the parent certificate of the lowest-level certificate.

Each CA certificate contains an issuer field that identifies the parent CA that issued the certificate.

2. Locates the PKI domain to which the parent certificate belongs.

3. Performs CRL checking in the PKI domain to check whether the parent certificate has been revoked. If it has been revoked, the certificate cannot be used.

This step will not be performed when CRL checking is disabled in the PKI domain.

4. Repeats the previous steps for upper-level certificates in the CA certificate chain until the root CA certificate is reached.

5. Verifies that each CA certificate in the certificate chain is issued by the named parent CA, starting from the root CA.

Verifying certificates with CRL checking

Restrictions and guidelines

CRL checking does not take effect if the revocation-check method none command is configured in the PKI domain.

Procedure

1. Enter system view.

system-view

2. Enter PKI domain view.

pki domain domain-name

3. (Optional.) Specify the URL of the CRL repository.

crl url url-string

By default, the URL of the CRL repository is not specified.

4. Enable CRL checking.

crl check enable

By default, CRL checking is enabled.

5. Return to system view.

quit

6. Obtain the CA certificate.

See "Obtaining certificates."

The PKI domain must have a CA certificate before you can verify certificates in it.

7. (Optional.) Obtain the CRL and save it locally.

pki retrieve-crl domain domain-name

To verify a non-root CA certificate and local certificates, the device automatically retrieves the CRL if the PKI domain has no CRL.

The newly obtained CRL overwrites the old one, if any.

The obtained CRL is issued by a CA in the CA certificate chain stored in the PKI domain.

8. Manually verify the validity of the certificates.

pki validate-certificate domain domain-name { ca | local }

Verifying certificates without CRL checking

1. Enter system view.

system-view

2. Enter PKI domain view.

pki domain domain-name

3. Disable CRL checking.

undo crl check enable

By default, CRL checking is enabled.

4. Return to system view.

quit

5. Obtain a CA certificate for the PKI domain.

See "Obtaining certificates."

The PKI domain must have a CA certificate before you can verify certificates in it.

6. Manually verify the certificate validity.

pki validate-certificate domain domain-name { ca | local }

This command is not saved in the configuration file.

Exporting certificates

About this task

You can export the CA certificate and the local certificates in a PKI domain to certificate files. The exported certificate files can then be imported back to the device or other PKI applications.

Restrictions and guidelines

To export all certificates in PKCS12 format, the PKI domain must have a minimum of one local certificate. If the PKI domain does not have any local certificates, the certificates in the PKI domain cannot be exported.

If you do not specify a file name when you export a certificate in PEM format, this command displays the certificate content on the terminal.

When you export a local certificate with RSA key pairs to a file, the certificate file name might be different from the file name specified in the command. The actual certificate file name depends on the purpose of the key pair contained in the certificate. For more information about the file naming rule, see the pki export command in Security Command Reference.

Procedure

1. Enter system view.

system-view

2. Export certificates.

¡ Export certificates in DER format.

pki export domain domain-name der { all | ca | local } filename filename

¡ Export certificates in PKCS12 format.

pki export domain domain-name p12 { all | local } passphrase p12-key filename filename

¡ Export certificates in PEM format.

pki export domain domain-name pem { { all | local } [ { 3des-cbc | aes-128-cbc | aes-192-cbc | aes-256-cbc | des-cbc } pem-key ] | ca } [ filename filename ]

Removing a certificate

About this task

You can remove certificates from a PKI domain in the following situations:

· Remove a CA certificate, local certificate, or peer certificate if the certificate has expired or is about to expire.

· Remove a local certificate if the certificate's private key is compromised, or if you want to request a new local certificate to replace the existing one.

Restrictions and guidelines

After you remove the CA certificate, the system automatically removes the local certificates, peer certificates, and CRLs from the domain.

To remove a local certificate and request a new certificate, perform the following tasks:

1. Remove the local certificate.

2. Use the public-key local destroy command to destroy the existing local key pair.

3. Use the public-key local create command to generate a new key pair.

4. Request a new certificate.

For more information about the public-key local destroy and public-key local create commands, see Security Command Reference.

Procedure

1. Enter system view.

system-view

2. Remove a certificate.

pki delete-certificate domain domain-name { ca | local | peer [ serial serial-num ] }

If you use the peer keyword without specifying a serial number, this command removes all peer certificates.

Configuring a certificate-based access control policy

About certificate-based access control policies

Certificate-based access control policies allow you to authorize access to a device (for example, an HTTPS server) based on the attributes of an authenticated client's certificate.

Access control rules and certificate attribute groups

A certificate-based access control policy is a set of access control rules (permit or deny statements), each associated with a certificate attribute group. A certificate attribute group contains multiple attribute rules, each defining a matching criterion for an attribute in the certificate issuer name, subject name, or alternative subject name field.

Certificate matching mechanism

If a certificate matches all attribute rules in a certificate attribute group associated with an access control rule, the system determines that the certificate matches the access control rule. In this scenario, the match process stops, and the system performs the access control action defined in the access control rule.

The following conditions describe how a certificate-based access control policy verifies the validity of a certificate:

· If a certificate matches a permit statement, the certificate passes the verification.

· If a certificate matches a deny statement or does not match any statements in the policy, the certificate is regarded invalid.

· If a statement is associated with a non-existing attribute group, or the attribute group does not have attribute rules, the certificate matches the statement.

· If the certificate-based access control policy specified for a security application (for example, HTTPS) does not exist, all certificates in the application pass the verification.

Procedure

1. Enter system view.

system-view

2. Create a certificate attribute group and enter its view.

pki certificate attribute-group group-name

3. Configure an attribute rule for issuer name, 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

By default, not attribute rules are configured.

4. Return to system view.

quit

5. Create a certificate-based access control policy and enter its view.

pki certificate access-control-policy policy-name

By default, no certificate-based access control policies exist.

6. Create a certificate access control rule.

rule [ id ] { deny | permit } group-name

By default, no certificate access control rules are configured, and all certificates can pass the verification.

You can create multiple certificate access control rules for a certificate-based access control policy.

Display and maintenance commands for PKI

Execute display commands in any view.

Task	Command
Display certificate-based access control policy information.	display pki certificate access-control-policy [ policy-name ]
Display certificate attribute group information.	display pki certificate attribute-group [ group-name ]
Display the contents of a certificate.	display pki certificate domain domain-name { ca \| local \| peer [ serial serial-num ] }
Display the certificate renewal status.	display pki certificate renew-status [ domain domain-name ]
Display certificate request status.	display pki certificate request-status [ domain domain-name ]
Display locally stored CRLs in a PKI domain.	display pki crl domain domain-name

‌

Troubleshooting PKI configuration

This section provides troubleshooting information for common problems with PKI.

Failed to obtain the CA certificate

Symptom

The CA certificate cannot be obtained.

Analysis

· The network connection is down, for example, because the network cable is damaged or the connectors have bad contact.

· No trusted CA is specified.

· The certificate request URL is incorrect or not specified.

· The system time of the device is not synchronized with the CA server.

· The CA server does not accept the source IP address specified in the PKI domain, or no source IP address is specified.

· The fingerprint of the root CA certificate is illegal.

Solution

1. Fix the network connection problems, if any.

2. Configure the trusted CA and all other required parameters in the PKI domain.

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

4. Synchronize the system time of the device with the CA server.

5. Specify the correct source IP address that the CA server can accept. For the correct settings, contact the CA administrator.

6. Verify the fingerprint of the CA certificate on the CA server.

7. If the problem persists, contact H3C Support.

Failed to obtain local certificates

Symptom

The local certificates can be obtained.

Analysis

· The network connection is down.

· The PKI domain does not have a CA certificate before you submit the local certificate request.

· The LDAP server is not configured or is incorrectly configured.

· No key pair is specified for certificate request in the PKI domain, or the specified key pair does not match the one contained in the local certificates to the obtained.

· No PKI entity is configured in the PKI domain, or the PKI entity configuration is incorrect.

· CRL checking is enabled, but the PKI domain does not have a CRL and cannot obtain one.

· The CA server does not accept the source IP address specified in the PKI domain, or no source IP address is specified.

· The system time of the device is not synchronized with the CA server.

Solution

1. Fix the network connection problems, if any..

2. Obtain or import the CA certificate.

3. Configure the correct LDAP server parameters.

4. Specify the key pair for certificate request, or remove the existing key pair, specify a new key pair, and submit a local certificate request again.

5. Check the registration policy on the CA or RA, and make sure the attributes of the PKI entity meet the policy requirements.

6. Obtain the CRL from the CRL repository.

7. Specify the correct source IP address that the CA server can accept. For the correct settings, contact the CA administrator.

8. Synchronize the system time of the device with the CA server.

9. If the problem persists, contact H3C Support.

Failed to request local certificates

Symptom

Local certificate requests cannot be submitted.

Analysis

· The network connection is down, for example, because the network cable is damaged or the connectors have bad contact.

· The PKI domain does not have a CA certificate before the local certificate request is submitted.

· The certificate request URL is incorrect or is not specified.

· The certificate request reception authority is incorrect or is not specified.

· Required PKI entity parameters are not configured or are incorrectly configured.

· No key pair is specified in the PKI domain for certificate request, or the key pair is changed during a certificate request process.

· Exclusive certificate request applications are running in the PKI domain.

· The CA server does not accept the source IP address specified in the PKI domain, or no source IP address is specified.

· The system time of the device is not synchronized with the CA server.

Solution

1. Fix the network connection problems, if any.

2. Obtain or import the CA certificate.

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

4. Use the certificate request from command to specify the correct certificate request reception authority.

5. Configure the PKI entity parameters as required by the registration policy on the CA or RA.

6. Specify the key pair for certificate request, or remove the existing key pair, specify a new key pair, and submit a local certificate request again.

7. Use the pki abort-certificate-request domain command to abort the certificate request.

8. Specify the correct source IP address that the CA server can accept. For the correct settings, contact the CA administrator.

9. Synchronize the system time of the device with the CA server.

10. If the problem persists, contact H3C Support.

Failed to obtain CRLs

Symptom

CRLs cannot be obtained.

Analysis

· The network connection is down, for example, because the network cable is damaged or the connectors have bad contact.

· The PKI domain does not have a CA certificate before you try to obtain CRLs.

· The URL of the CRL repository is not configured and cannot be obtained from the CA certificate or local certificates in the PKI domain.

· The specified URL of the CRL repository is incorrect.

· The device tries to obtain CRLs through SCEP, but it experiences the following problems:

¡ The PKI domain does not have local certificates.

¡ The key pairs in the certificates have been changed.

¡ The PKI domain has incorrect URL for certificate request.

· The CRL repository uses LDAP for CRL distribution. However, the IP address or host name of the LDAP server is neither contained in the CRL repository URL nor configured in the PKI domain.

· The CA does not issue CRLs.

· The CA server does not accept the source IP address specified in the PKI domain, or no source IP address is specified.

Solution

1. Fix the network connection problems, if any.

2. Obtain or import the CA certificate.

3. If the URL of the CRL repository cannot be obtained, verify that the following conditions exist:

¡ The URL for certificate request is valid.

¡ A local certificate has been successfully obtained.

¡ The local certificate contains a public key that matches the locally stored key pair.

4. Make sure the LDAP server address is contained in the CRL repository URL, or is configured in the PKI domain.

5. Make sure the CA server support publishing CRLs.

6. Specify a correct source IP address that the CA server can accept. For the correct settings, contact the CA administrator.

7. If the problem persists, contact H3C Support.

Failed to import the CA certificate

Symptom

The CA certificate cannot be imported.

Analysis

· CRL checking is enabled, but the device does not have a CRL in the PKI domain and cannot obtain one.

· The specified format in which the CA certificate file is to be imported does not match actual certificate file format.

Solution

1. Use the undo crl check enable command to disable CRL checking in the PKI domain.

2. Make sure the format of the imported file is correct.

3. If the problem persists, contact H3C Support.

Failed to import the local certificate

Symptom

The local certificate cannot be imported.

Analysis

· The PKI domain does not have a CA certificate, and the local certificate file to be imported does not contain the CA certificate chain.

· CRL checking is enabled, but the device does not have a CRL in the PKI domain and cannot obtain one.

· The specified format in which the local certificate file is to be imported does not match actual certificate file format.

· The device and the certificate do not have the local key pair.

· The certificate has been revoked.

· The certificate is out of the validity period.

· The system time is incorrect.

Solution

1. Obtain or import the CA certificate.

2. Use the undo crl check enable command to disable CRL checking, or obtain the correct CRL before you import certificates.

3. Make sure the format of the file to be imported is correct.

4. Make sure the certificate file contains the private key.

5. Make sure the certificate is not revoked.

6. Make sure the certificate is valid.

7. Configure the correct system time for the device.

8. If the problem persists, contact H3C Support.

Failed to export certificates

Symptom

Certificates cannot be exported.

Analysis

· The PKI domain does not have local certificates when you export all certificates in PKCS12 format.

· The specified export path does not exist.

· The specified export path is illegal.

· The public key of the local certificate to be exported does not match the public key of the key pair configured in the PKI domain.

· The storage space of the device is full.

Solution

1. Obtain or request local certificates first.

2. Use the mkdir command to create the required path.

3. Specify a correct export path.

4. Configure the correct key pair in the PKI domain.

5. Clear up the storage space of the device.

6. If the problem persists, contact H3C Support.

Failed to set the storage path

Symptom

The storage path for certificates or CRLs cannot be set.

Analysis

· The specified storage path does not exist.

· The specified storage path is illegal.

· The storage space of the device is full.

Solution

1. Use the mkdir command to create the path.

2. Specify a valid storage path for certificates or CRLs.

3. Clear up the storage space of the device.

4. If the problem persists, contact H3C Support.

14-Security Configuration Guide

PKI terminology

Digital certificate

Fingerprint of root CA certificate

Certificate revocation list

CA policy

PKI architecture

PKI entity

CA

RA

Certificate/CRL repository

Retrieval, usage, and maintenance of a digital certificate

VPN

Secure emails

Web security

PKI tasks at a glance

Restrictions and guidelines for configuring the DN for the PKI entity

Configuring the individual DN attributes

Configuring the full DN string

Configuring a PKI domain

About this task

Procedure

Specifying the certificate request reception authority

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Manually submitting an online certificate request

About this task

Procedure

About this task

Procedure

Aborting a certificate request

About this task

Procedure

Obtaining certificates

About this task

Restrictions and guidelines

Prerequisites

Procedure

Verifying PKI certificates

Restrictions and guidelines

Procedure

Exporting certificates

About this task

Restrictions and guidelines

Procedure

Removing a certificate

About this task

Restrictions and guidelines

Procedure

Configuring a certificate-based access control policy

Access control rules and certificate attribute groups

Certificate matching mechanism

Display and maintenance commands for PKI

Troubleshooting PKI configuration

Symptom

Analysis

Solution

Failed to obtain local certificates

Symptom

Analysis

Solution

Failed to request local certificates

Symptom

Analysis

Solution

Failed to obtain CRLs

Symptom

PKI task s at a glance