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

H3C's PKI system provides certificate management for IPsec and 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. The most common standard is X.509 v3.

This document involves local certificate and CA certificate. A local certificate is a digital certificate signed by a CA for an entity, and 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 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. Because different CAs might use different methods to examine the 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 or a common database. It stores and manages information like certificate requests, certificates, keys, CRLs and logs when it 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 obtain 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 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 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 CRLs on 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 (for instance, IPsec) 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 verify each other's identity through digital certificates.

PKI configuration task list

Task	Remarks
Configuring a PKI entity	Required.
Configuring a PKI domain	Required.
Requesting a certificate: · Configuring automatic certificate request · Manually requesting a certificate	Required. Use either method.
Obtaining certificates	Optional.
Verifying PKI certificates	Optional.
Destroying the local RSA key pair	Optional.
Removing a certificate	Optional.
Configuring a certificate access control policy	Optional.

Configuring a PKI entity

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:

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

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

To configure a PKI entity:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an entity and enter its view.	pki entity entity-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-name name	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.	ip ip-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-unit org-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 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. 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 by these 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 request management. It receives the registration request from an entity, examines its qualification, and determines whether to ask the CA to sign a digital certificate. The RA only examines 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. H3C recommends you to deploy an independent RA.

· URL of the registration server—An entity sends a certificate request to the registration server 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 might 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.

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

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. The number of PKI domains supported by the device varies by device model. For more information, see About the H3C Access Controllers Configuration Guides.
3. Specify the trusted CA.	ca identifier name	No trusted CA is specified by default. The CA name is required only when you obtain a CA certificate. It is not used for local certificate request.
4. Specify the entity for certificate request.	certificate request entity entity-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 of the 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-server ip ip-address [ port port-number ] [ version version-number ]	Optional. No LDP server is 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 of the root certificate must be verified manually. No fingerprint is configured by default.

Requesting a certificate

When you request a certificate for an entity, the 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 offline mode or online mode. In offline mode, a certificate request is submitted to a CA by an out-of-band means such as phone, disk, or email.

Online certificate request falls into manual mode and auto mode.

Configuring automatic certificate request

In auto mode, an entity automatically requests a certificate from the CA server if it has no local certificate for an application working with PKI. The entity requests the certificate through SCEP, 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 an automatically 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.

To configure automatic certificate request:

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 ] *	The default certificate request mode is manual.

Manually requesting a certificate

In manual mode, you must submit a local certificate request for an entity. Before the request, you must obtain 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 information about RSA key pair configuration, see "Managing public keys."

Configuration guidelines

· If a PKI domain already has a local certificate, creating an RSA key pair might result in 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, see Security Command Reference.

· A newly created key pair overwrites the existing one. If you perform the public-key local create command in the presence of a local RSA key pair, the system asks 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 to request 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 the pki request-certificate domain command with the pkcs10 filename filename option.

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

· In FIPS mode, you cannot import MD5 certificates.

Configuration procedure

To manually request a certificate:

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 manual.	certificate request mode manual	Optional. Manual by default.
4. Return to system view.	quit	N/A
5. Retrieve a CA certificate manually.	See "Obtaining certificates"	N/A
6. Generate a local RSA key pair.	public-key local create rsa	By default, no local RSA key pair exists. In FIPS mode, the RSA key modulus length must be 2048 bits.
7. Submit a local certificate request manually.	pki request-certificate domain domain-name [ password ] [ pkcs10 [ filename filename ] ]	This command is not saved in the configuration file.

Obtaining certificates

You can download CA certificates or local certificates from the CA server and save them locally. To do so, use either the offline mode or the online mode. In offline mode, you must obtain a certificate by an out-of-band means such as 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, make sure to complete LDAP server configuration.

If a PKI domain already has a CA certificate, you cannot obtain another CA certificate for it. This restriction helps avoid inconsistency between the certificate and registration information resulting from configuration changes. To obtain 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 obtain certificates:

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

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Retrieve a certificate manually

· In online mode:
pki retrieval-certificate { ca | local } domain domain-name

· In offline mode:

¡ To retrieve a CA certificate:
pki import-certificate ca domain domain-name { der | pem } [ filename filename ]

¡ To retrieve a local certificate:
pki import-certificate local domain domain-name { der | p12 | pem } [ filename filename ]

Use either command.

The pki retrieval-certificate configuration is not saved in the configuration file.

Verifying PKI certificates

A certificate needs to be verified before you use it. Verifying a certificate examines that the certificate is signed by the CA and that the certificate has neither expired nor been revoked.

You can specify whether CRL checking is required in certificate verification. If you enable CRL checking, CRLs are used in verification of a certificate. In this case, make sure to obtain the CA certificate and CRLs to the local device before the certificate verification. If you disable CRL checking, you only need to obtain 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 takes precedence over that carried in the CRLs.

Verifying certificates with 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. Specify the URL of the CRL distribution point.	crl url url-string	Optional. No CRL distribution point URL is specified by default.
4. 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.
5. Enable CRL checking.	crl check enable	Optional. Enabled by default.
6. Return to system view.	quit	N/A
7. Retrieve the CA certificate.	See "Obtaining certificates"	N/A
8. Retrieve the CRLs.	pki retrieval-crl domain domain-name	This command is not saved in the configuration file.
9. Verify the validity of a certificate.	pki validate-certificate { ca \| local } domain domain-name	N/A

Verifying certificates 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 check disable	By default, CRL checking is enabled.
4. Return to system view.	quit	N/A
5. Retrieve the CA certificate.	See "Obtaining certificates"	N/A
6. Verify the validity of the certificate.	pki validate-certificate { ca \| local } domain domain-name	N/A

Destroying the local RSA 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 key pair, and then create a pair to request a new certificate.

To destroy the local RSA key pair:

Step	Command
1. Enter system view.	system-view
2. Destroy the local RSA key pair.	public-key local destroy rsa

Removing 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 remove a certificate:

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

Configuring a certificate access control policy

By configuring a certificate access control policy, you can further control access to the server, providing additional security for the server.

To configure a certificate 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 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. 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 access control policy and enter its view.	pki certificate access-control-policy policy-name	No access control policy exists by default.
6. Configure a certificate 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 } domain domain-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 about one or all certificate attribute groups.	display pki certificate attribute-group { group-name \| all } [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about one or all certificate access control policies.	display pki certificate access-control-policy { policy-name \| all } [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.

PKI configuration examples

CAUTION:

· When the CA uses Windows Server, the SCEP add-on is required. You must use the certificate request from ra command to specify that the entity request a certificate from an RA.

· When the CA uses RSA Keon, the SCEP add-on is not required. You must use the certificate request from ca command to specify that the entity request a certificate from a CA.

Certificate request from an RSA Keon CA server

Network requirements

As shown in Figure 2, the AC submits a local certificate request to the CA server.

The AC acquires the CRLs for certificate verification.

Figure 2 Network diagram

Configure the CA server

1. Create a CA server named myca:

In this example, configure these basic attributes on the CA server:

¡ Nickname—Name of the trusted CA.

¡ Subject DN—DN information of the CA, including the Common Name (CN), Organization Unit (OU), Organization (O), and Country (C).

You can use the default values for the other attributes.

2. Configure extended attributes:

Enter the management interface for the CA server, and do the following for the jurisdiction configuration:

¡ Select the proper extension profiles.

¡ Enable the SCEP autovetting function.

¡ Specify the IP address list for SCEP autovetting.

3. Configure the CRL distribution behavior.

After completing the previous configuration, you must perform CRL related configurations. In this example, select the local CRL distribution mode of HTTP and set the HTTP URL to http://4.4.4.133:447/myca.crl.

Configure the AC

1. Synchronize the system time of the AC with the CA server, so that the AC can correctly request a certificate.

2. Configure the entity name as aaa and the common name as name.

<AC> system-view

[AC] pki entity aaa

[AC-pki-entity-aaa] common-name name

[AC-pki-entity-aaa] quit

3. Configure the PKI domain:

# Create PKI domain torsa and enter its view.

[AC] pki domain torsa

# Configure the name of the trusted CA as myca.

[AC-pki-domain-torsa] ca identifier myca

# Configure the URL of the registration server in the format of http://host:port/Issuing Jurisdiction ID, where Issuing Jurisdiction ID is a hexadecimal string generated on the CA server.

[AC-pki-domain-torsa] certificate request url http://4.4.4.133:446/ c95e970f632d27be5e8cbf80e971d9c4a9a93337

# Set the registration authority to CA.

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

# Specify the entity for certificate request as aaa.

[AC-pki-domain-torsa] certificate request entity aaa

# Configure the URL for the CRL distribution point.

[AC-pki-domain-torsa] crl url http://4.4.4.133:447/myca.crl

[AC-pki-domain-torsa] quit

4. Generate a local host key pair using RSA:

[AC] public-key local create rsa

The range of public key size is (512 ~ 2048).

NOTES: If the key modulus is greater than 512,

It will take a few minutes.

Press CTRL+C to abort.

Input the bits in the modulus [default = 1024]:

Generating Keys...

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++

5. Apply for certificates:

# Retrieve the CA certificate and save it locally.

[AC] pki retrieval-certificate ca domain torsa

Retrieving CA/RA certificates. Please wait a while......

The trusted CA's finger print is:

MD5 fingerprint:EDE9 0394 A273 B61A F1B3 0072 A0B1 F9AB

SHA1 fingerprint: 77F9 A077 2FB8 088C 550B A33C 2410 D354 23B2 73A8

Is the finger print correct?(Y/N):y

Saving CA/RA certificates chain, please wait a moment......

CA certificates retrieval success.

# Retrieve CRLs and save them locally.

[AC] pki retrieval-crl domain torsa

Connecting to server for retrieving CRL. Please wait a while.....

CRL retrieval success!

# Request a local certificate manually.

[AC]pki request-certificate domain torsa

Certificate is being requested, please wait......

Enrolling the local certificate,please wait a while......

[AC]

Certificate request Successfully!

Saving the local certificate to device......

Done!

Verifying the configuration

# Use the following command to view information about the local certificate acquired.

<AC> display pki certificate local domain torsa

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

9A96A48F 9A509FD7 05FFF4DF 104AD094

Signature Algorithm: sha1WithRSAEncryption

Issuer:

C=cn

O=org

OU=test

CN=myca

Validity

Not Before: Jan 8 09:26:53 2007 GMT

Not After : Jan 8 09:26:53 2008 GMT

Subject:

CN=aaa

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (1024 bit)

Modulus (1024 bit):

00D67D50 41046F6A 43610335 CA6C4B11

F8F89138 E4E905BD 43953BA2 623A54C0

EA3CB6E0 B04649CE C9CDDD38 34015970

981E96D9 FF4F7B73 A5155649 E583AC61

D3A5C849 CBDE350D 2A1926B7 0AE5EF5E

D1D8B08A DBF16205 7C2A4011 05F11094

73EB0549 A65D9E74 0F2953F2 D4F0042F

19103439 3D4F9359 88FB59F3 8D4B2F6C

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 CRL Distribution Points:

URI:http://4.4.4.133:447/myca.crl

Signature Algorithm: sha1WithRSAEncryption

836213A4 F2F74C1A 50F4100D B764D6CE

B30C0133 C4363F2F 73454D51 E9F95962

EDE9E590 E7458FA6 765A0D3F C4047BC2

9C391FF0 7383C4DF 9A0CCFA9 231428AF

987B029C C857AD96 E4C92441 9382E798

8FCC1E4A 3E598D81 96476875 E2F86C33

75B51661 B6556C5E 8F546E97 5197734B

C8C29AC7 E427C8E4 B9AAF5AA 80A75B3C

You can also use some other display commands to view detailed information about the CA certificate and CRLs. For more information about the display pki certificate ca domain and display pki crl domain commands, see Security Command Reference.

Certificate request from a Windows 2003 CA server

Network requirements

As shown in Figure 3, configure PKI entity AC to request a local certificate from the CA server.

Figure 3 Network diagram

Configure the CA server

1. Install the certificate server suites:

a. From the start menu, select Control Panel > Add or Remove Programs.

b. Select Add/Remove Windows Components > Certificate Services.

c. Click Next to begin the installation.

2. Install the SCEP add-on:

The Windows 2003 server does not support SCEP by default. Install the SCEP add-on so that the AC can register and obtain its certificate automatically. After the SCEP add-on installation completes, a URL is displayed, which you must configure on the AC as the URL of the server for certificate registration.

3. Modify the certificate service attributes:

a. From the start menu, select Control Panel > Administrative Tools > Certificate Authority.

If you install the certificate service component and SCEP add-on successfully, there should be two certificates issued by the CA to the RA.

b. In the navigation tree, riight-click the CA server and select Properties > Policy Module.

c. Click Properties, and then select Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate.

4. Modify the Internet Information Services (IIS) attributes:

a. From the start menu, select Control Panel > Administrative Tools > Internet Information Services (IIS) Manager.

b. From the navigation tree, select Web Sites.

c. Right-click Default Web Site and select Properties > Home Directory.

d. In the Local path box, specify the path for certificate service.

e. Specify an available port number as the TCP port number for the default website to avoid conflict with existing services. In this example, port 8080 is used.

Configure the AC

1. Synchronize the system time of the AC with the CA server, so that the AC can properly request a certificate.

2. Configure the entity DN:

# Configure the entity name as aaa and the common name as AC.

<AC> system-view

[AC] pki entity aaa

[AC-pki-entity-aaa] common-name AC

[AC-pki-entity-aaa] quit

3. Configure the PKI domain:

# Create PKI domain torsa and enter its view.

[AC] pki domain torsa

# Configure the name of the trusted CA as myca.

[AC-pki-domain-torsa] ca identifier myca

# Configure the URL of the registration server in the format of http://host:port/ certsrv/mscep/mscep.dll, where host:port indicates the IP address and port number of the CA server.

[AC-pki-domain-torsa] certificate request url http://4.4.4.1:8080/certsrv/mscep/mscep.dll

# Set the registration authority to RA.

[AC-pki-domain-torsa] certificate request from ra

# Specify the entity for certificate request as aaa.

[AC-pki-domain-torsa] certificate request entity aaa

4. Generate a local key pair using RSA:

[AC] public-key local create rsa

The range of public key size is (512 ~ 2048).

NOTES: If the key modulus is greater than 512,

It will take a few minutes.

Press CTRL+C to abort.

Input the bits in the modulus [default = 1024]:

Generating Keys...

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++

5. Apply for certificates:

# Retrieve the CA certificate and save it locally.

[AC] pki retrieval-certificate ca domain torsa

Retrieving CA/RA certificates. Please wait a while......

The trusted CA's finger print is:

MD5 fingerprint:766C D2C8 9E46 845B 4DCE 439C 1C1F 83AB

SHA1 fingerprint:97E5 DDED AB39 3141 75FB DB5C E7F8 D7D7 7C9B 97B4

Is the finger print correct?(Y/N):y

Saving CA/RA certificates chain, please wait a moment......

CA certificates retrieval success.

# Request a local certificate manually.

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

Certificate is being requested, please wait......

[AC]

Enrolling the local certificate,please wait a while......

Certificate request Successfully!

Saving the local certificate to device......

Done!

Verifying the configuration

# Use the following command to view information about the local certificate acquired.

<AC> display pki certificate local domain torsa

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

48FA0FD9 00000000 000C

Signature Algorithm: sha1WithRSAEncryption

Issuer:

CN=CA server

Validity

Not Before: Nov 21 12:32:16 2007 GMT

Not After : Nov 21 12:42:16 2008 GMT

Subject:

CN=AC

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (1024 bit)

Modulus (1024 bit):

00A6637A 8CDEA1AC B2E04A59 F7F6A9FE

5AEE52AE 14A392E4 E0E5D458 0D341113

0BF91E57 FA8C67AC 6CE8FEBB 5570178B

10242FDD D3947F5E 2DA70BD9 1FAF07E5

1D167CE1 FC20394F 476F5C08 C5067DF9

CB4D05E6 55DC11B6 9F4C014D EA600306

81D403CF 2D93BC5A 8AF3224D 1125E439

78ECEFE1 7FA9AE7B 877B50B8 3280509F

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Subject Key Identifier:

B68E4107 91D7C44C 7ABCE3BA 9BF385F8 A448F4E1

X509v3 Authority Key Identifier:

keyid:9D823258 EADFEFA2 4A663E75 F416B6F6 D41EE4FE

X509v3 CRL Distribution Points:

URI:http://l00192b/CertEnroll/CA%20server.crl

URI:file://\\l00192b\CertEnroll\CA server.crl

Authority Information Access:

CA Issuers - URI:http://l00192b/CertEnroll/l00192b_CA%20server.crt

CA Issuers - URI:file://\\l00192b\CertEnroll\l00192b_CA server.crt

1.3.6.1.4.1.311.20.2:

.0.I.P.S.E.C.I.n.t.e.r.m.e.d.i.a.t.e.O.f.f.l.i.n.e

Signature Algorithm: sha1WithRSAEncryption

81029589 7BFA1CBD 20023136 B068840B

(Omitted)

You can also use some other display commands to view detailed information about the CA certificate. For more information about the display pki certificate ca domain command, see Security Command Reference.

Certificate access control policy configuration example

Network requirements

· As shown in Figure 4, the client accesses the remote HTTP Secure (HTTPS) server through the HTTPS protocol.

· SSL is configured to make sure that only legal clients log into the HTTPS server.

· Create a certificate access control policy to control access to the HTTPS server.

Figure 4 Network diagram

Configuration procedure

For more information about SSL configuration, see "Configuring SSL."

The PKI domain to be referenced by the SSL policy must be created in advance. For more information about PKI domain configuration, see "Configure the PKI domain" in "Configure the AC."

1. Configure the SSL policy for the HTTPS server to use:

<AC> system-view

[AC] ssl server-policy myssl

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

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

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

2. Configure the certificate attribute group:

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

[AC] pki certificate attribute-group mygroup1

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

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

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

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

[AC] pki certificate attribute-group mygroup2

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

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

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

3. Configure the certificate access control policy

# Create the certificate access control policy of myacp and add two access control rules.

[AC] pki certificate access-control-policy myacp

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

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

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

4. Apply the SSL server policy and certificate access control policy to HTTPS service and enable HTTPS service.

# Apply SSL server policy myssl to HTTPS service.

[AC] ip https ssl-server-policy myssl

# Apply the certificate access control policy of myacp to HTTPS service.

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

# Enable HTTPS service.

[AC] ip https enable

Troubleshooting PKI

Failed to obtain the CA certificate

Symptom

Failed to obtain 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 physically proper.

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 local certificates

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

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

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 obtain CRLs

Symptom

Failed to obtain 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 obtained before you try to obtain CRLs.

· The IP address of LDAP server is not configured.

· The CRL distribution URL 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 physically proper.

2. Retrieve a CA certificate.

3. Specify the IP address of the LDAP server.

4. Specify the CRL distribution URL.

5. Re-configure the LDAP version.

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

07-Security Configuration Guide

Overview

PKI terms

Digital certificate

CRL

CA policy

PKI architecture

Entity

CA

RA

PKI repository

PKI operation

PKI configuration task list

Configuring a PKI domain

Requesting a certificate

Configuring automatic certificate request

Configuration guidelines

Configuration procedure

Obtaining certificates

Verifying PKI certificates

Destroying the local RSA key pair

Removing a certificate

Configuring a certificate access control policy

Displaying and maintaining PKI

Network requirements

Configure the CA server

Verifying the configuration

Network requirements

Configure the CA server

Configure the AC

Verifying the configuration

Network requirements

Configuration procedure

Troubleshooting PKI

Symptom

Analysis

Solution

Failed to request local certificates

Symptom

Analysis

Solution

Failed to obtain CRLs

Symptom

Analysis

Solution

Cloud & AI

InterConnect

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Resources

Partner Business Management

Company Information

News & Events

Contact Us