No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


CLI-based Configuration Guide - Security

AR500, AR510, and AR530 V200R007

This document describes the configurations of Security, including AAA, DAA,NAC, BRAS Access, ACL, Firewall, Deep Security Defense, Local Attack Defense;Attack Defense, Traffic Suppression, ARP Security, Port Security, DHCP Snooping, IPSG, URPF, PKI, SSL, HTTPS, Keychain, separating the management plane from the service plane, security risks.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
PKI Implementation

PKI Implementation

Working Process

On a PKI network, PKI is configured to apply to a CA for a local certificate for a specified entity and verify certificate validity. The PKI working process is as follows:

  1. An entity applies to an RA for a certificate.
  2. The RA authenticates the entity's identity and sends the entity's identity information and public key as a digital signature to a CA.
  3. The CA authenticates the digital signature and issues a certificate to the RA.
  4. The RA receives the certificate and notifies the entity that the certificate is issued.
  5. The entity obtains the certificate and uses it to securely communicate with other entities in encryption and digital signature modes.
  6. The entity sends a revocation request to the CA to revoke a certificate. The CA approves the entity's revocation request and updates the CRL.

Working Principle

PKI uses public key theories and technologies to provide secure services for various network applications.

Because public keys are transmitted on a network, the public key encryption system must solve public key management problems. The digital certificate mechanism in the PKI better solves the problem. PKI core technologies involve digitical certificate application, issuing, usage, and revocation.

Certificate Enrollment

Certificate enrollment is a process in which an entity registers with a CA and obtains a certificate from the CA. During this process, the subject provides the identity information and public key, which will be added to the certificate issued to the subject.

A subject can apply to a CA for a certificate online or offline. In offline enrollment mode, the subject provides the identity information and public key in outband mode(for example, through phone call, disk, or email). In online enrollment mode, an enrollment request can be initiated manually or automatically. The following enrollment modes are often used:

  • PKCS#10 mode (offline certificate enrollment)

    If a PKI entity use cannot SCEP to request a certificate online, it can save the certificate request information in PKCS#10 format to a file, and then send the file to the CA in outband mode.

  • Simple Certificate Enrollment Protocol (SCEP) mode (online certificate enrollment and downloading)

    A PKI entity uses the Hypertext Transfer Protocol (HTTP) to communicate with a CA or a registration authority (RA). It sends an SCEP certificate enrollment request to apply for a local certificate or sends a certificate download request to download the CA/RA certificate or local certificate. This mode is most commonly used.

  • Self-signed certificate

    A PKI entity issues a self-signed certificate, in which the certificate issuer and subject are the same.

Certificate Renewal

The device supports the certificate renewal function. It applies for a shadow certificate before the current certificate expires. When the current certificate expires, the shadow certificate takes effect.

The device completes a certificate enrollment process to obtain the shadow certificate.

The certificate renewal function can be used only when the CA server supports this function.

Certificate Downloading

An end entity can use the SCEP protocol to query and download issued certificates from a CA server. It can also use the CDP mechanism to download certificates from the specified CDP URL. Entities can download their own certificates, CA certificates, or certificates of other entities.

Certificate Revocation

Certificate revocation unbinds the public key of a subject from the subject's identity. A certificate subject needs to revoke its certificate when the subject's identity, information, or public key changes or the service for the subject ceases. A CA issues a CRL to revoke certificates, and an end entity submits a certificate revocation request to the CA server administrator in outband mode.

The administrator requires the end entity to provide the challenge password. The challenge password has been sent to the CA with a PKCS10# certificate enrollment request during certificate enrollment. If the challenge password provided by the end entity is the same as that saved on the CA server, the CA issues a CRL to revoke the certificate of the end entity.

CRL Downloading

CAs and RAs send CRLs to end entities only when they receive CRL query requests from end entities. Entities download CRLs from CAs or RAs in CDP or SCEP mode.

If a CA supports CDPs, it encodes a CDP URL and encapsulates the URL in the certificate issued to an end entity. The end entity then downloads the CRL from the URL.

If the certificate of an end entity does not contain the CDP information and no CDP URL is configured on the end entity, the end entity sends an SCEP message to request the CRL from the CA server. The SCEP message contains the certificate issuer name and certificate serial number.

Certificate Status Checking

When an end entity verifies a peer certificate, it checks the status of the peer certificate. For example, the end entity checks whether the peer certificate expires and whether the certificate is in a CRL. An end entity uses any of the following methods to check the peer certificate status:

  • CRL

    If a CA supports CRL distribution points (CDPs), a certificate that the CA issues to an end entity contains the CDP information, specifying how and where to obtain the CRL for the certificate. The end entity then uses the specified method to find the CRL from the specified location and download the CRL.

    If a CDP URL is configured in a PKI domain, the end entity bound to the PKI domain obtains the CRL from the CDP URL.

  • OCSP

    If a certificate does not specify any CDP and no CDP URL is configured in the PKI domain, an end entity can use the Online Certificate Status Protocol (OCSP) to check the certificate status.

  • None

    This mode is used when no CRL or OCSP server is available to an end entity or the end entity does not need to check the peer certificate status. In this mode, an end entity does not check whether a certificate has been revoked.

Certificate Legality Verification

When an end entity needs to authenticate a peer, it checks the validity of the peer certificate. For example, when an end entity needs to set up a secure tunnel or connection with a peer, it verifies the peer certificate and issuer's certificate. If the certificate of a CA is invalid or has expired, all certificates issued by this CA are invalid. This invalidation seldom occurs because a device usually renews the CA/RA certificate before the certificate expires.

During certificate authentication, the local device must obtain the peer certificate and the following information: trusted CA certificate, CRL, local certificate and private key in the local certificate, and certificate authentication configuration.

The local device authenticates a certificate as follows:

  1. Uses the public key of the CA to verify the digital signature of the CA.
  2. Checks whether the certificate has expired.
  3. Checks whether the certificate has been revoked in CRL, OCSP, or None mode.

Certificate Chain Authentication

A user must obtain the public key of a certificate issuer before verifying the private key signature in the certificate. Each CA certificate is certified by an upper-layer CA, and the certificate authentication process is performed along a certificate chain. A certificate chain ends at a trustpoint, which is the root CA holding a self-signed certificate or a trusted intermediate CA.

A certificate chain is a series of trusted certificates, which starts at an end entity's certificate and ends at a root certificate. Entities that have the same root CA or subordinate CA and have obtained CA certificates can authenticate each other's certificates (peer certificates). Authentication of a peer certificate chain ends at the first trusted certificate or CA.

In brief, certificate chain authentication starts at an entity certificate and ends at a trustpoint certificate.

Updated: 2019-05-25

Document ID: EDOC1000097287

Views: 13692

Downloads: 40

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Previous Next