H3C S5500-SI Series Ethernet Switches Operation Manual(V1.01)

HomeSupportSwitchesH3C S5500 Switch SeriesConfigure & DeployConfiguration GuidesH3C S5500-SI Series Ethernet Switches Operation Manual(V1.01)
35-PKI Configuration
Title Size Download
35-PKI Configuration 168 KB

Chapter 1  PKI Configuration

When configuring PKI, go to these sections for information you are interested in:

l           Introduction to PKI

l           PKI Configuration Task List

l           Displaying and Maintaining PKI

l           PKI Configuration Examples

l           Troubleshooting PKI

1.1  Introduction to PKI

This section covers these topics:

l           PKI Overview

l           PKI Terms

l           Architecture of PKI

l           Applications of PKI

l           Operation of PKI

1.1.1  PKI Overview

Public Key Infrastructure (PKI) is a system designed for providing information security through public key technologies and digital certificates and verifying the identities of the digital certificate owners.

PKI employs digital certificates, which are bindings of certificate owner identity information and public keys. PKI allows users to request certificates, use certificates, and revoke certificates. By leveraging digital certificates and relevant services like certificate distribution and blacklist publication, PKI supports authentication the entities involved in communication, and thus guaranteeing the confidentiality, integrity and non-repudiation of data.

1.1.2  PKI Terms

I. Digital certificate

A digital certificate is a file signed by a certificate authority (CA) that contains a public key and the related user identity information. A simplest digital certificate contains a public key, an entity name, and a digital signature from the CA. Generally, a digital certificate also includes the validity period of the key, the name of the CA and the sequence number of the certificate. A digital certificate must comply with the international standard of ITUTX.5.9. This manual involves two types of certificates: local certificate and CA certificate. A local certificate is a digital certificate signed by a CA for an entity, while a CA certificate, also known as root certificate, is signed by the CA for itself.

II. CRL

An existing certificate may need to be revoked when, for example, the user name changes, the private key leaks, or the user stops the business. Revoking a certificate is to remove the binding of the public key with the user identity information. In PKI, the revocation is made well known through certificate revocation lists (CRLs). Whenever a certificate is revoked, the CA publishes one or more CRLs to announce that the certificate is invalid. The CRLs contains the serial numbers of all certificates that are revoked and function an effective way for checking the validity of certificates.

A CA may publish multiple CRLs when the number of revoked certificates is so large that publishing them in a single CRL may degrade network performance.

III. CA policy

A CA policy is a set of criteria that a CA follows in managing certificate requests and in issuing, revoking, and publishing CRLs. Usually, a CA advertises its policy in the form of certification practice statement (CPS), which can be acquired through out-of-band means such as phone, disk, and e-mail or through other means. Since different CAs may 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.

1.1.3  Architecture of PKI

A PKI system consists of entities, a CA, a registration authority (RA) and a PKI repository, as shown in Figure 1-1.

Figure 1-1 PKI architecture

I. Entity

An entity is an end user of PKI products or services, such as a person, an organization, a device like a switch, or a process running on a computer.

II. CA

A CA is a trusted entity responsible for issuing and managing digital certificates. A CA issues certificates, specifies the validity period of a certificate, and revokes a certificate as needed by publishing CRLs.

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

IV. PKI repository

A PKI repository includes a Lightweight Directory Access Protocol (LDAP) server and some common databases that stores and manages information like certificate requests, certificates, keys, CRLs and logs while providing 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.

1.1.4  Applications of PKI

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.

I. VPN

A virtual private network (VPN) is a proprietary data communication network built over 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.

II. Secure E-mail

E-mails also require confidentiality, integrity, authentication, and non-repudiation. PKI can address these needs. The secure E-mail protocol that is currently developing rapidly is Secure/Multipurpose Internet Mail Extensions (S/MIME), which is based on PKI and allows for transfer of encrypted mails and mails with signature.

III. Web security

For Web security, two peers can establish a Secure Sockets Layer (SSL) connection first for transparent and secure communications at the application layer. With PKI, SSL enables communications with encryption between a browser and a server. Both the communication parties can identify the identity of each other through digital certificates.

1.1.5  Operation of PKI

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

2)         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 validates 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, while the CA approves the request, updates the CRLs and transfers the CRLs to the LDAP server.

1.2  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 Certificate Request in Auto Mode

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 Validation

Optional

Destroying a Local RSA Key Pair

Optional

Deleting a Certificate

Optional

Configuring an Access Control Policy

Optional

 

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

l           Common name of the entity.

l           Country code of the entity, a standard 2-character code. For example, CN represents China and US represents the United States of America.

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

l           IP address of the entity.

l           Locality where the entity resides.

l           Organization to which the entity belongs.

l           Unit of the entity in the organization.

l           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 request may be rejected.

 

Follow these steps to configure an entity DN:

To do…

Use the command…

Remarks

Enter system view

system-view

Create an entity and enter its view

pki entity entity-name

Required

No entity exists by default.

Configure the common name for the entity

common-name name

Optional

No common name is specified by default.

Configure the country code for the entity

country country-code-str

Optional

No country code is specified by default.

Configure the FQDN for the entity

fqdn name-str

Optional

No FQDN is specified by default.

Configure the IP address for the entity

ip ip-address

Optional

No IP address is specified by default.

Configure the locality of the entity

locality locality-name

Optional

No locality is specified by default.

Configure the organization name  for the entity

organization org-name

Optional

No organization is specified by default.

Configure the unit name for the entity

organization-unit org-unit-name

Optional

No unit is specified by default.

Configure the state or province for the entity

state state-name

Optional

No state or province is specified by default.

 

&  Note:

l      Currently, up to two entities can be created on a device.

l      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 does not respond to the certificate request.

 

1.4  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, and has only local significance.

A PKI domain is defined by these parameters:

l           Trusted CA

An entity requests a certificate from a trusted CA.

l           Entity

A certificate applicant uses an entity to provide its identity information to a CA.

l           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. You are recommended to deploy an independent RA.

l           URL of the enrollment server

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

l           Polling interval and count

After an applicant makes a certificate request, the CA may 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.

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

l           Fingerprint for root certificate validation

Upon receiving the root certificate of the CA, an entity needs to validate the fingerprint of the root certificate, namely, the hash value of the root certificate content. This hash value is unique to every certificate. The entity will reject the root certificate if the fingerprint of the root certificate does not match the one configured for the PKI domain.

Follow these steps to configure a PKI domain:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a PKI domain and enter its view

pki domain domain-name

Required

No PKI domain exists by default.

Specify the trusted CA

ca identifier name

Required

No trusted CA is specified by default.

Specify the entity for certificate request

certificate request entity entity-name

Required

No entity is specified by default.

The specified entity must exist.

Specify the authority for certificate request

certificate request from { ca | ra }

Required

No authority is specified by default.

Configure the URL of the server for certificate request

certificate request url url-string

Required

No URL is configured by default.

Configure the polling interval and maximum number of attempts 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.

Specify the LDAP server

ldap-server ip ip-address [ port port-number ] [ version version-number ]

Optional

No LDP server is specified by default.

Configure the fingerprint for root certificate validation

root-certificate fingerprint { md5 | sha1 } string

Optional

No fingerprint is configured by default.

 

&  Note:

l      Currently, up to two PKI domains can be created on a device.

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

 

1.5  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 that the CA may issue to the entity. A certificate request can be submitted to a CA in two ways: online and offline. In offline mode, a certificate request is submitted to a CA by an “out-of-band” means such as phone, disk, or e-mail.

Online certificate request falls into two categories: manual mode and auto mode.

1.5.1  Submitting a Certificate Request in Auto Mode

In auto mode, an entity automatically requests a certificate through the SCEP protocol when it has no local certificate or the present certificate is about to expire.

Follow these steps to configure an entity to submit a certificate request in auto mode:

To do…

Use the command…

Remarks

Enter system view

system-view

Enter PKI domain view

pki domain domain-name

Set the certificate request mode to auto

certificate request mode auto [ key-length key-length | password { cipher | simple } password ] *

Required

Manual by default

 

1.5.2  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 is 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, while the public key is transferred to the CA along with some other information. For detailed information about RSA key pair configuration, refer to SSH Configuration.

Follow these steps to submit a certificate request in manual mode:

To do…

Use the command…

Remarks

Enter system view

system-view

Enter PKI domain view

pki domain domain-name

Set the certificate request mode to manual

certificate request mode manual

Optional

Manual by default

Return to system view

quit

Retrieve a CA certificate manually

Refer to Retrieving a Certificate Manually

Required

Generate a local RSA key pair

public-key local create rsa

Required

No local RSA key pair exists by default.

Submit a local certificate request

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

Required

 

&  Note:

l      If a PKI domain has already a local certificate, creating an RSA key pair will result in inconsistency between the key pair and certificate. To generate a new RSA key pair, delete the local certificate and then issue the public-key local create rsa command.

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

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

l      When it is impossible to request a certificate from the CA through SCEP, you can save the request information by using the pki request-certificate domain command with the pkcs10 and filename keywords, and then send the file to the CA by an out-of-band means.

l      Make sure the clocks of an entity and the CA are synchronous. Otherwise, the validity period of the certificate may be abnormal.

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

 

1.6  Retrieving a Certificate Manually

You can download an existing CA certificate or local certificate from the CA server and save it locally. To do so, you can use two ways: online and offline. In offline mode, you need to retrieve a certificate by an out-of-band means like FTP, disk, e-mail and then import it into the local PKI system.

Certificate retrieval serves two purposes:

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

l           Prepare for certificate validation.

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

Follow these steps to retrieve a certificate manually:

To do…

Use the command…

Remarks

Enter system view

system-view

Retrieve a certificate manually

Online

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

Required

Use either command

Offline

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

 

  Caution:

l      If a PKI domain has already a CA certificate, you cannot retrieve another CA certificate for it. This is in order to avoid inconsistency between the certificate and enrollment information due to related configuration changes. To retrieve a new CA certificate, use the pki delete-certificate command to delete the existing CA certificate and local certificate first.

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

 

1.7  Configuring PKI Certificate Validation

A certificate needs to be validated before being used. Validating a certificate is to check that the certificate is signed by the CA and that the certificate has neither expired nor been revoked.

Before validating a certificate, you need to retrieve the CA certificate.

You can specify whether CRL checking is required in certificate validation. If you enable CRL checking, CRLs will be used in validation of a certificate.

I. Configuring CRL-checking-enabled PKI certificate validation

Follow these steps to configure CRL-checking-enabled PKI certificate validation:

To do…

Use the command…

Remarks

Enter system view

system-view

Enter PKI domain view

pki domain domain-name

Specify the URL of the CRL distribution point

crl url url-string

Optional

No CRL distribution point URL is specified by default.

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.

Enable CRL checking

crl check enable

Optional

Enabled by default

Return to system view

quit

Retrieve the CA certificate

Refer to Retrieving a Certificate Manually

Required

Retrieve CRLs

pki retrieval-crl domain domain-name

Required

Verify the validity of a certificate

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

Required

 

II. Configuring CRL-checking-disabled PKI certificate validation

Follow these steps to configure CRL-checking-disabled PKI certificate validation:

To do…

Use the command…

Remarks

Enter system view

system-view

Enter PKI domain view

pki domain domain-name

Disable CRL checking

crl check disable

Required

Enabled by default

Return to system view

quit

Retrieve the CA certificate

Refer to Retrieving a Certificate Manually

Required

Verify the validity of the certificate

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

Required

 

&  Note:

l      The CRL update period refers to the interval at which the entity downloads CRLs from the CRL server. The CRL update period configured manually is prior to that specified in the CRLs.

l      The pki retrieval-crl domain configuration will not be saved in the configuration file.

 

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

Follow these steps to destroy a local RSA key pair:

To do…

Use the command…

Remarks

Enter system view

system-view

Destroy a local RSA key pair

public-key local destroy rsa

Required

 

&  Note:

For details about the public-key local destroy rsa command, refer to SSH Commands.

 

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

Follow these steps to delete a certificate:

To do…

Use the command…

Remarks

Enter system view

system-view

Delete certificates

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

Required

 

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

Follow these steps to configure a certificate attribute-based access control policy:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a certificate attribute group and enter its view

pki certificate attribute-group group-name

Required

No certificate attribute group exists by default.

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

There is no restriction on the issuer name, certificate subject name and alternative subject name by default.

Return to system view

quit

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

pki certificate access-control-policy policy-name

Required

No access control policy exists by default.

Configure a certificate attribute-based access control rule

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

Required

No access control rule exists by default.

 

  Caution:

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

 

1.11  Displaying and Maintaining PKI

To do…

Use the command…

Remarks

Display the contents  or request status of a certificate

display pki certificate { { ca | local } domain domain-name | request-status }

Available in any view

Display CRLs

display pki crl domain domain-name

Available in any view

Display information about one or all certificate attribute groups

display pki certificate attribute-group { group-name | all }

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 }

Available in any view

 

1.12  PKI Configuration Examples

 

  Caution:

l      The SCEP plug-in is required when you use the Windows Server as the CA. In this case, when configuring the PKI domain, you need to use the certificate request from ra command to specify that the entity requests a certificate from an RA.

l      The SCEP plug-in is not required when RSA Keon is used. In this case, when configuring a PKI domain, you need to use the certificate request from ca command to specify that the entity requests a certificate from a CA.

 

1.12.1  Configuring a PKI Entity to Request a Certificate from a CA

 

&  Note:

RSA Keon is used on the CA server in this configuration example.

 

I. Network requirements

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

l           The device acquires the CRLs for certificate validation.

II. Network diagram

Figure 1-2 Diagram for configuring a PKI entity to request a certificate from a CA

III. Configuration procedure

On the CA server, complete the following configurations:

1)         Create a CA server named myca

In this example, you need to configure theses basic attributes on the CA server at first:

l           Nickname: Name of the trusted CA.

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

The other attributes may be left using the default values.

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

3)         Configure the CRL publishing behavior

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

After the above configuration, make sure that the system clock of the device is synchronous to that of the CA, allowing the device to request certificates and retrieve CRLs properly.

On the Switch, perform the following configurations:

1)         Configure the entity DN

# 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

2)         Configure the PKI domain

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

3)         Generate a local key pair using RSA

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

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

# Apply for a local certificate manually.

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

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

Certificate request Successfully!

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

Done!

5)         Verify your configuration

# Use the following command to view 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

                    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 to view detailed information about the CA certificate and CRLs. Refer to the parts related to display pki certificate ca domain and display pki crl domain commands in PKI Commands.

1.12.2  Configuring a Certificate Attribute-Based Access Control Policy

I. Network requirements

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

l           SSL is configured to ensure that only legal clients log into the HTTPS server.

l           Create a certificate attribute-based access control policy to control access to the HTTPS server.

II. Networking diagram

Figure 1-3 Diagram for configuring a certificate attribute-based access control policy

III. Configuration procedure

 

&  Note:

l      For detailed information about SSL configuration, refer to SSL-HTTPS Configuration.

l      For detailed information about HTTPS configuration, refer to SSL-HTTPS Configuration.

l      The PKI domain to be referenced by the SSL policy must be created in advance. For detailed configuration of the PKI domain, refer to Configure the 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-based access control policy

# Create the certificate attribute-based 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-based 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-based access control policy of myacp to HTTPS service.

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

# Enable HTTPS service.

[Switch] ip https enable

1.13  Troubleshooting PKI

1.13.1  Failed to Retrieve a CA Certificate

I. Symptom

Failed to retrieve a CA certificate.

II. Analysis

Possible reasons include these:

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

l           No trusted CA is specified.

l           The URL of the enrollment server for certificate request is not correct or not configured.

l           No RA is specified.

l           The system clock of the device is not synchronized with that of the CA.

III. Solution

l           Make sure that the network connection is physically proper.

l           Check that the required commands are configured properly.

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

l           Configures the RA for certificate request.

l           Synchronize the system clock of the device with that of the CA.

1.13.2  Failed to Request a Local Certificate

I. Symptom

Failed to request a local certificate.

II. Analysis

Possible reasons include these:

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

l           No CA certificate has been retrieved.

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

l           No trusted CA is specified.

l           The URL of the enrollment server for certificate request is not correct or not configured.

l           No RA is configured.

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

III. Solution

l           Make sure that the network connection is physically proper.

l           Retrieve a CA certificate.

l           Regenerate a key pair.

l           Specify a trusted CA.

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

l           Configure the RA for certificate request.

l           Configure the required entity DN parameters.

1.13.3  Failed to Retrieve CRLs

I. Symptom

Failed to retrieve CRLs.

II. Analysis

Possible reasons include these:

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

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

l           The IP address of LDAP server is not configured.

l           The URL for CRL distribution is not configured.

l           The LDAP server version is wrong.

III. Solution

l           Make sure that the network connection is physically proper.

l           Retrieve a CA certificate.

l           Specify the IP address of the LADP server.

l           Specify the URL for CRL distribution.

l           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
新华三官网