10-Security Configuration Guide

HomeSupportRoutersH3C SR8800 Router SeriesConfigure & DeployConfiguration GuidesH3C SR8800 Configuration Guide-Release3347-6W10310-Security Configuration Guide
18-PKI Configuration
Title Size Download
18-PKI Configuration 202.56 KB

PKI overview

The Public Key Infrastructure (PKI) is a general security infrastructure for providing information security through public key technologies.

PKI, also called asymmetric key infrastructure, uses a key pair to encrypt and decrypt the data. The key pair consists of a private 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 that 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 applications

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

VPN

A virtual private network (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.

How PKI works

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

PKI configuration task list

Complete the following tasks to configure PKI:

 

Task

Remarks

Configuring an entity DN

Required.

Configuring a PKI domain

Required.

Submitting a PKI certificate request

Submitting a certificate request in auto mode

Required.

Use either approach.

Submitting a certificate request in manual mode

Retrieving a certificate manually

Optional.

Configuring PKI certificate verification

Optional.

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

 

 

NOTE:

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.

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:

·     Up to two entities can be created on a device.

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

3.     Specify the trusted CA.

ca identifier name

No trusted CA is specified by default.

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.

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.

 

 

NOTE:

·     Up to two PKI domains can be created on a device.

·     The CA name is required only when you retrieve a CA certificate. It is not used when in local certificate request.

·     The URL of the server for certificate request does not support domain name resolution.

 

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 request falls into manual mode and auto mode.

Submitting a certificate request in auto mode

In auto mode, an entity automatically requests a certificate from the CA 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.

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

 

 

NOTE:

If a certificate will expire or has expired, the entity does not initiate a re-request automatically, and the service using the certificate might be interrupted. To have a new local certificate, request one manually.

 

Submitting a certificate request in manual mode

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

The goal of retrieving a CA certificate will 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 information. For more information about RSA and ECDSA key pair configuration, see the chapter “Managing public keys.”

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

 

 

NOTE:

·     If a PKI domain already has a local certificate, creating an RSA key pair will 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.

·     A newly created key pair will overwrite the existing one. If you perform the public-key local create command in the presence of a local RSA or ECDSA key pair, the system will ask you whether you want to overwrite the existing one.

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

·     When it is impossible 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 will be abnormal.

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

 

Retrieving a certificate manually

You can download CA certificates or local certificate 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

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

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.

 

CAUTION

CAUTION:

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

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

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

 

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 device before the certificate verification. If you disable CRL checking, you only need to retrieve the CA certificate.

Configuring CRL-checking-enabled PKI certificate verification

To configure CRL-checking-enabled PKI certificate verification:

 

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 “Retrieving a certificate manually

N/A

8.     Retrieve CRLs.

pki retrieval-crl domain domain-name

N/A

9.     Verify the validity of a certificate.

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

N/A

 

 

NOTE:

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

·     The pki retrieval-crl domain command cannot be saved in the configuration file.

·     The URL of the CRL distribution point does not support domain name resolution.

 

Configuring CRL-checking-disabled PKI certificate verification

To configure CRL-checking-disabled PKI certificate verification:

 

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 }

 

 

NOTE:

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-based access control policy, you can further control access to the server, providing additional security for the server.

To configure a certificate attribute-based access control policy:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

pki certificate attribute-group group-name

No certificate attribute group exists by default.

3.     Configure 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-based 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-based access control rule.

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

No access control rule exists by default.

A certificate attribute group must exist to be associated with a rule.

 

Displaying and maintaining PKI

 

Task

Command

Remarks

Display the contents or request status of a certificate.

display pki certificate { { ca | local } domain domain-name } [ | { 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-based access control policies.

display pki certificate access-control-policy { policy-name | all } [ | { begin | exclude | include } regular-expression ]

Available in any view

 

PKI configuration examples

 

CAUTION

CAUTION:

·     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 need to use 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 need to use the certificate request from ca command to specify that the entity requests a certificate from a CA.

 

Requesting a certificate from a CA server running RSA Keon

Network requirements

The device submits a local certificate request to the CA server.

The device acquires the CRLs for certificate verification.

Figure 2 Network diagram

 

Configuration procedure

1.     Configure the CA server:

# Create a CA server named myca.

In this example, you need to configure these basic attributes on the CA server at 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).

The other attributes might be left using the default values.

# Configure extended attributes.

After configuring the basic attributes, you need to perform configuration on the jurisdiction configuration page of the CA server. This includes selecting the proper extension profiles, enabling the SCEP autovetting function, and adding the IP address list for SCEP autovetting.

# 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 that the system clock of the device is synchronous to that of the CA, so that the device can request certificates and retrieve CRLs properly.

2.     Configure the router:

a.     Configure the entity DN:

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

<Router> system-view

[Router] pki entity aaa

[Router-pki-entity-aaa] common-name router

[Router-pki-entity-aaa] quit

b.     Configure the PKI domain:

# Create PKI domain torsa and enter its view.

[Router] pki domain torsa

# Configure the name of the trusted CA as myca.

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

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

# Set the registration authority to CA.

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

# Specify the entity for certificate request as aaa.

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

# Configure the URL for the CRL distribution point.

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

[Router-pki-domain-torsa] quit

c.     Generate a local key pair using RSA:

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

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

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

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

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

 

d.     Apply for certificates:

# Retrieve the CA certificate and save it locally.

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

[Router] pki retrieval-crl domain torsa

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

CRL retrieval success!

# Request a local certificate manually.

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

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

[Router]

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

Certificate request Successfully!

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

Done!

3.     Verify your configuration:

# Display information about the retrieved local certificate.

[Router] 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=router

        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

                    2B

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

Requesting a certificate from a CA server running Windows 2003 Server

Network requirements

Configure PKI entity Router 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 router 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 router 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 on the CA server in the navigation tree 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.     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 on 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 time of the router is synchronous to that of the CA server, so that the router can request a certificate normally.

Configuring the router

1.     Configure the entity DN

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

<Router> system-view

[Router] pki entity aaa

[Router-pki-entity-aaa] common-name router

[Router-pki-entity-aaa] quit

2.     Configure the PKI domain:

# Create PKI domain torsa and enter its view.

[Router] pki domain torsa

# Configure the name of the trusted CA as myca.

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

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

# Set the registration authority to RA.

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

# Specify the entity for certificate request as aaa.

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

3.     Generate a local key pair using RSA:

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

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

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

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

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

 

4.     Apply for certificates:

# Retrieve the CA certificate and save it locally.

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

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

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

[Router]

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.

[Router] 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=router

        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

                    6B

                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.

Troubleshooting PKI

CA certificate cannot be retrieved

Symptom

CA certificate cannot be retrieved.

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 device is not synchronized with that of the CA.

Solution

1.     Make sure that the network connection is physically proper.

2.     Check that the required commands are configured properly.

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 device with that of the CA.

Local certificate cannot be retrieved

Symptom

Local certificate cannot be retrieved.

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

CRLs cannot be retrieved

Symptom

CRLs cannot be retrieved.

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.

Solution

1.     Make sure that 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.

  • Cloud & AI
  • InterConnect
  • Intelligent Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become a Partner
  • Partner Resources
  • Partner Business Management
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网