This help contains the following topics:

·     Introduction

¡     Digital certificate and certificate revocation list

¡     PKI architecture

¡     PKI applications

¡     Certificate management

¡     Certificate access control policy

·     Restrictions and guidelines

Introduction

Public Key Infrastructure (PKI) is an asymmetric key infrastructure to encrypt and decrypt data for securing network services.

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.

The PKI system of the device provides certificate management for IPsec and SSL.

Digital certificate and certificate revocation list

Digital certificate

A digital certificate is an electronic document signed by a certificate authority (CA). A digital certificate 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).

·     Certificate subject (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.

This help 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.

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

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. Revoked certificates should not be trusted.

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

·     The certificate subject information is changed.

·     The private key is compromised.

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

PKI architecture

A PKI system consists of certificate subjects, CAs, RAs and a certificate/CRL repository.

Certificate subject

A certificate subject is an end user using PKI certificates. The certificate applicant can be an operator, an organization, a device, or a process running on a computer.

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

·     Certificate subject name, which further includes the common name, country code, state or province name, locality, organization name, and organization unit name. If you configure the certificate subject name, a common name is required.

·     FQDN of the certificate applicant. It identifies a PKI entity in the network.

·     IP address of the certificate applicant.

CA

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

RA

The 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 certificate distribution point that stores certificates and CRLs, and distributes the certificates and CRLs to certificate applicants. 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.

PKI applications

The PKI technology can meet security requirements of online transactions. As an infrastructure, PKI has a wide range of applications. Here 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.

Certificate management

The device manages certificates based on PKI domains and provides the PKI domain-based certificate service for applications such as IPsec and SSL. A PKI domain contains enrollment information for a certificate subject, including the key pairs for certificate request and the certificate usage extensions.

Importing certificates

You can import the CA certificate and local certificates related to a PKI domain from the CA.

Use this method 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.

Before you import certificates to a PKI domain, complete the following tasks:

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

·     To import a local certificate, a CA certificate chain must exist in the PKI domain, or be contained in the certificate to be imported. If the CA certificate chain is not available, import it before you import the local certificate.

When you import a local certificate, follow these restrictions and guidelines:

·     If the local certificate contains the CA certificate chain, you can import the CA certificate and the local certificate at the same time.

·     If the local certificate does not contain the CA certificate chain, but the CA certificate already exists in a PKI domain, you can directly import the certificate.

·     If the certificate file to be imported contains the root certificate, the system will prompt you to confirm the root certificate's fingerprint before the import. Contact the CA administrator to obtain the correct root certificate fingerprint.

·     If the local certificate to be imported contains a key pair, the system will prompt for the challenge password used for encrypting the private key. Contact the CA administrator to obtain the challenge password.

·     When you import a local certificate file that contains a key pair, the device saves the key pair in the PKI domain as follows.

¡     If the PKI domain already contains a key pair that matches key pair in the certificate file, the device prompts whether you want to overwrite the existing key pair.

¡     If the PKI domain does not have a key pair, the device creates a key pair according to the key algorithm and the purpose of the key pair in the certificate file. The PKI domain name will be used as the key pair name.

¡     If the PKI domain contains a key pair that is different from the key pair in the certificate file, you must specify a different name to save the key pair in the certificate file.

You can import the CA certificate to a PKI domain when either of the following conditions is met:

·     The CA certificate to be imported is the root CA certificate or contains the certificate chain with the root certificate.

·     The CA certificate contains a certificate chain without the root certificate, but can form a complete certificate chain with an existing CA certificate on the device.

Exporting certificates

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.

Requesting certificates

Before you request a local certificate for a certificate subject in a PKI domain, make sure a CA certificate already exists in the PKI domain. The CA certificate will be used to verify the validity of the obtained local certificate.

To request a certificate for a certificate subject in a PKI domain, perform the following tasks:

1.     Configure the certificate subject.

2.     Use the certificate subject in a PKI domain. In the PKI domain, configure the certificate enrollment settings such as the key pair for certificate request.

The public key of the key pair is sent along other information in the certificate request to the CA. The CA then signs the request and generates the requested certificate.

If you specify a nonexistent key pair in the PKI domain, the system automatically generates the key pair according to the key pair settings when generating the certificate request.

3.     Generate a certificate request for the certificate subject in the PKI domain.

4.     Submit the certificate request to the CA by using an out-of-band method, such as phone or email.

Certificate access control policy

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

A certificate access control policy is a set of permit or deny rules. Each rule contains a set of certificate attribute filters. A certificate attribute filter filters certificates based on an attribute in the certificate issuer name, subject name, or alternative subject name field. A certificate matches a rule if it matches all the certificate attribute filters in the rule.

The device matches a received certificate against the rules on the rule list of the certificate access policy from top to bottom. The match process stops once a matching rule is found.

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

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

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

Restrictions and guidelines

·     Whether the identity categories are required or optional depends on the CA policy. Follow the CA policy to configure the certificate subject settings.

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