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 of 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 IP Security (IPsec), Secure Sockets Layer (SSL), and WLAN Authentication and Privacy Infrastructure (WAPI).

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 user name 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. As different CAs might use different methods to check 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 retrieve local and CA certificates of its own as well as certificates of other entities.

PKI operation

In a PKI-enabled network, an entity can request a local certificate from the CA and the device can check the validity of certificates. Here is how it operates:

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

PKI applications

The PKI technology can meet the security requirements of online transactions. As an infrastructure, PKI has a wide range of applications. Here are some application examples.

· Virtual private network—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 Secure/Multipurpose Internet Mail Extensions (S/MIME), which is based on PKI and allows for transfer of encrypted mails with signature.

· Web security—For Web security, two peers can establish an SSL connection first for transparent and secure communications at the application layer. With PKI, SSL enables encrypted communications between a browser and a server. Both of the communication parties can verify each other’s identity through digital certificates.

PKI configuration task list

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

Configuring an entity DN

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

An entity DN is defined by these parameters:

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

· Fully qualified domain name (FQDN) of the entity, a unique identifier of an entity on the network. It consists of a host name and a domain name and can be resolved to an IP address. For example, www.whatever.com is an FQDN, where www is a host name and whatever.com a domain name.

· 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 an entity DN:

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 switch.
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 switch 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, checks its qualification, and determines whether to ask the CA to sign a digital certificate. The RA only checks the application qualification of an entity; it does not issue any certificate. Sometimes, the registration management function is provided by the CA, in which case no independent RA is required. H3C recommends you to deploy an independent RA.

· URL of the registration server—An entity sends a certificate request to the registration server through Simple Certification Enrollment Protocol (SCEP), a dedicated protocol for an entity to communicate with a CA.

· 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. You can create up to 32 PKI domains on a switch.
3. Specify the trusted CA.	ca identifier name	No trusted CA is specified by default. The CA name is required only when you retrieve a CA certificate. It is not used for requesting the local certificate.
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 of the server for certificate request 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.

Submitting a PKI certificate request

When requesting a certificate, an entity introduces itself to the CA by providing its identity information and public key, which will be the major components of the certificate. A certificate request can be submitted to a CA in 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 requests can be submitted in manual mode or auto mode.

Submitting a certificate request in auto mode

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. For example, when PKI certificate authentication is used, if no local certificate is available during IKE negotiation, the entity automatically requests one, and saves the local certificate after retrieving it from the CA. If the PKI domain has no CA certificate before the entity submits the certificate request, the entity automatically retrieves the CA certificate first.

If 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 an entity to submit a certificate request in auto mode:

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

Submitting a certificate request in manual mode

In manual mode, you must retrieve a CA certificate, generate a local RSA key pair, and submit a local certificate request for an entity.

The CA certificate in the PKI domain is used to verify the authenticity and validity of a local certificate. Generating an RSA key pair is an important step in certificate request. The key pair includes a public key and a private key. The private key is kept by the user. The public key is transferred to the CA along with some other identify information. For more information about RSA and ECDSA key pair configuration, see "Managing public keys."

Configuration guidelines

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

· When you generate a local RSA or ECDSA key pair, the new one can overwrite the existing one. The system gives prompt before you confirm to overwrite the existing one.

· If a PKI domain already has a local certificate, do not request another certificate for it. Otherwise, inconsistency might exist between the certificate and the registration information when the configuration changes. To request a new certificate, first use the pki delete-certificate command to delete the existing local certificate and the local CA certificate.

· If you cannot 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 entity and the CA are synchronous in system time. Otherwise, the validity period of the certificate is abnormal.

· The pki request-certificate domain configuration is not saved in the configuration file.

Configuration procedure

To submit a certificate request in manual mode:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PKI domain view.	pki 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 "Retrieving a certificate manually"	N/A
6. Generate a local RSA or ECDSA key pair.	public-key local create { ecdsa \| rsa }	No local RSA or ECDSA key pair exists by default.
7. Submit a local certificate request manually.	pki request-certificate domain domain-name [ password ] [ pkcs10 [ filename filename ] ]	N/A

Retrieving a certificate manually

You can download CA certificates and 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 retrieve a certificate by an out-of-band means like FTP, disk, or email, and then import it into the local PKI system.

Certificate retrieval serves the following purposes:

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

· Prepare for certificate verification

Configuration guidelines

· Before retrieving a local certificate in online mode, complete LDAP server configuration.

· If a PKI domain already has a CA certificate, do not retrieve another CA certificate for it. Otherwise, inconsistency might exist between the certificate and registration information if the configuration changes. To retrieve a new CA certificate, first use the pki delete-certificate command to delete the existing local CA certificate and the local certificate.

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

· Make sure the system time of the switch falls in the validity period of the certificate so that the certificate is valid.

Configuration procedure

To retrieve a certificate manually:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Retrieve a certificate manually.	· In online mode: pki retrieval-certificate { ca \| local } domain domain-name · In offline mode: pki import-certificate { ca \| local } domain domain-name { der \| p12 \| pem } [ filename filename ]	Use either command.

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:
pki import-certificate { ca | local } domain domain-name { der | p12 | pem } [ filename filename ]

Use either command.

Configuring PKI certificate verification

A certificate needs to be verified before being used. Verifying a certificate will check that the certificate is signed by the 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 will be used in verification of a certificate. In this case, be sure to retrieve the CA certificate and CRLs to the local switch before the certificate verification. If you disable CRL checking, you only need to retrieve the CA certificate.

Configuring PKI certificate verification 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. This command defines the interval at which the entity downloads CRLs from the CRL server. The configured value takes precedence over that carried in the CRLs.
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 "Retrieving a certificate manually"	N/A
8. Retrieve CRLs.	pki retrieval-crl domain domain-name	N/A The pki retrieval-crl domain command cannot be saved in the configuration file.
9. Verify the validity of a certificate.	pki validate-certificate { ca \| local } domain domain-name	N/A

Configuring PKI certificate verification without CRL checking

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

Destroying a local RSA or ECDSA key pair

A certificate has a lifetime, which is determined by the CA. When the private key leaks or the certificate is about to expire, you can destroy the old RSA or ECDSA key pair and then create a pair to request a new certificate.

To destroy a local RSA key pair:

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

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

Deleting a certificate

When a certificate requested manually is about to expire or you want to request a new certificate, you can delete the current local certificate or CA certificate.

To delete a certificate:

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

Configuring an access control policy

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

To configure a certificate attribute 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 attribute 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 attribute 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 attribute access control policies.	display pki certificate access-control-policy { policy-name \| all } [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.

PKI configuration examples

The SCEP add-on is required when you use the Windows Server as the CA. In this case, when you configure the PKI domain, you must the certificate request from ra command to specify that the entity requests a certificate from an RA.

The SCEP add-on is not required when RSA Keon is used. In this case, when you configure a PKI domain, you must use the certificate request from ca command to specify that the entity requests a certificate from a CA.

Certificate request from an RSA Keon CA server

Network requirements

The switch submits a local certificate request to the CA server and the switch acquires the CRLs for certificate verification.

Figure 2 Network diagram

Configuring the CA server

1. Create a CA server named myca:

a. Configure these basic attributes on the CA server first:

¡ 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).

b. Use the default settings for the other attributes.

2. Configure extended attributes.

After configuring the basic attributes, you need to perform configuration on the jurisdiction configuration page of the CA server. Select the proper extension profiles, enable the SCEP autovetting function, and add the IP address list for SCEP autovetting.

3. Configure the CRL distribution behavior.

After completing the configuration, you need to 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.

After the configuration, make sure the system clock of the switch is synchronous to that of the CA, so that the switch can request certificates and retrieve CRLs correctly.

Configuring the switch

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

<Switch> system-view

[Switch] pki entity aaa

[Switch-pki-entity-aaa] common-name switch

[Switch-pki-entity-aaa] quit

# Create PKI domain torsa and enter its view.

[Switch] pki domain torsa

# Configure the name of the trusted CA as myca.

[Switch-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.

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

# Set the registration authority to CA.

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

# Specify the entity for certificate request as aaa.

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

# Configure the URL for the CRL distribution point.

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

[Switch-pki-domain-torsa] quit

# Generate local RSA key pairs.

[Switch] 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...

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

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

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

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

# Retrieve the CA certificate and save it locally.

[Switch] 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.

[Switch] pki retrieval-crl domain torsa

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

CRL retrieval success!

# Request a local certificate manually.

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

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

[Switch]

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

Certificate request Successfully!

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

Done!

Verifying the configuration

# Display information about the local certificate acquired.

[Switch] 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=switch

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, for example, display pki certificate ca domain and display pki crl domain commands, to view detailed information about the CA certificate and CRLs. For more information about the commands, see Security Command Reference.

Certificate request from a Windows 2003 CA server

Network requirements

Configure PKI entity Switch to request a local certificate from the CA server.

Figure 3 Network diagram

Configuring the CA server

1. Install the certificate service suites:

a. Select Control Panel > Add or Remove Programs from the start menu.

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

c. Click Next to begin the installation.

2. Install the SCEP add-on:

As a CA server running the Windows 2003 server does not support SCEP by default, you need to install the SCEP add-on so that the switch can register and obtain its certificate automatically. After the SCEP add-on installation completes, a URL is displayed, which you need to configure on the switch as the URL of the server for certificate registration.

3. Modify the certificate service attributes:

a. Select Control Panel > Administrative Tools > Certificate Authority from the start menu.

If the CA server and SCEP add-on have been installed successfully, there should be two certificates issued by the CA to the RA.

b. Right-click the CA server in the navigation tree and select Properties > Policy Module.

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

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

a. Select Control Panel > Administrative Tools > Internet Information Services (IIS) Manager from the start menu.

b. Select Web Sites from the navigation tree.

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

d. Specify the path for certificate service in the Local path text box.

To avoid conflict with existing services, specify an available port number as the TCP port number of the default website.

After completing the configuration, check that the system clock of the switch is synchronous to that of the CA server, so that the switch can request a certificate.

Configuring the switch:

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

<Switch> system-view

[Switch] pki entity aaa

[Switch-pki-entity-aaa] common-name switch

[Switch-pki-entity-aaa] quit

# Create PKI domain torsa and enter its view.

[Switch] pki domain torsa

# Configure the name of the trusted CA as myca.

[Switch-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.

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

# Set the registration authority to RA.

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

# Specify the entity for certificate request as aaa.

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

# Generate local RSA key pairs.

[Switch] 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...

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

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

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

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

# Retrieve the CA certificate and save it locally.

[Switch] 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.

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

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

[Switch]

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

Certificate request Successfully!

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

Done!

Verifying the configuration

# Display information about the retrieved local certificate.

[Switch] display pki certificate local domain torsa

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

48FA0FD9 00000000 000C

Signature Algorithm: sha1WithRSAEncryption

Issuer:

CN=myca

Validity

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

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

Subject:

CN=switch

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 more information about the CA certificate. For more information about the display pki certificate ca domain command, see Security Command Reference.

Certificate attribute access control policy configuration

Network requirements

The client accesses the remote HTTP Security (HTTPS) server through the HTTPS protocol.

Configure SSL to make sure only legal clients log into the HTTPS server. Create a certificate attribute 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."

For more information about HTTPS configuration, see Fundamentals Configuration Guide.

The PKI domain to be referenced by the SSL policy must be created in advance. For information about how to configure a PKI domain, see "Configuring a PKI domain."

1. Configure the HTTPS server:

# Configure the SSL policy for the HTTPS server to use.

<Switch> system-view

[Switch] ssl server-policy myssl

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

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

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

2. Configure the certificate attribute group:

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

[Switch] pki certificate attribute-group mygroup1

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

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

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

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

[Switch] pki certificate attribute-group mygroup2

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

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

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

3. Configure the certificate attribute access control policy:

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

[Switch] pki certificate access-control-policy myacp

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

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

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

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

# Apply SSL server policy myssl to HTTPS service.

[Switch] ip https ssl-server-policy myssl

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

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

# Enable HTTPS service.

[Switch] ip https enable

Troubleshooting PKI

Failed to retrieve a CA certificate

Symptom

Failed to retrieve a CA certificate.

Analysis

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

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

4. Specify the authority for certificate request.

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

Failed to request a local certificate

Symptom

Failed to request a local certificate.

Analysis

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

· No CA certificate has been retrieved.

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

· No trusted CA is specified.

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

· No authority is specified for certificate request.

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

Solution

1. Make sure the network connection is physically proper.

2. Retrieve a CA certificate.

3. Regenerate a key pair.

4. Specify a trusted CA.

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

6. Specify the authority for certificate request.

7. Configure the required entity DN parameters.

Failed to retrieve CRLs

Symptom

Failed to retrieve CRLs.

Analysis

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

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

· The IP address of LDAP server is not configured.

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

11-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 an entity DN

Configuring a PKI domain

Submitting a PKI certificate request

Submitting a certificate request in auto mode

Submitting a certificate request in manual mode

Configuration guidelines

Configuration procedure

Retrieving a certificate manually

Configuring PKI certificate verification

Destroying a local RSA or ECDSA key pair

Deleting a certificate

Configuring an access control policy

Displaying and maintaining PKI

Certificate request from an RSA Keon CA server

Network requirements

Configuring the CA server

Configuring the switch

Verifying the configuration

Network requirements

Configuring the CA server

Configuring the switch:

Verifying the configuration

Certificate attribute access control policy configuration

Network requirements

Configuration procedure

Troubleshooting PKI

Symptom

Analysis

Solution

Failed to request a local certificate

Symptom

Analysis

Solution

Failed to retrieve CRLs

Symptom

Analysis

Solution

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us