Pki (Sran15.1 02) PDF

SingleRAN
PKI Feature Parameter Description
Issue 02
Date 2019-08-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. i

SingleRAN
PKI Feature Parameter Description Contents
Contents
1 Change History.............................................................................................................................. 1
1.1 SRAN15.1 02 (2019-08-30)........................................................................................................................................... 1
1.2 SRAN15.1 01 (2019-06-06)........................................................................................................................................... 1
1.3 SRAN15.1 Draft B (2019-03-18)................................................................................................................................... 1
1.4 SRAN15.1 Draft A (2018-12-30)................................................................................................................................... 2
2 About This Document.................................................................................................................. 4

2.1 General Statements......................................................................................................................................................... 4
2.2 Applicable RAT.............................................................................................................................................................. 4
2.3 Features in This Document.............................................................................................................................................4
3 Overview......................................................................................................................................... 6
4 PKI.................................................................................................................................................... 8
4.1 Principles........................................................................................................................................................................ 8
4.1.1 PKI Architecture..........................................................................................................................................................8
4.1.1.1 Introduction.............................................................................................................................................................. 8
4.1.1.2 CA.............................................................................................................................................................................9
4.1.1.3 RA...........................................................................................................................................................................10
4.1.1.4 Certificate & CRL Database...................................................................................................................................10
4.1.2 Certificates and Files Used by NEs........................................................................................................................... 10
4.1.2.1 Device Certificate................................................................................................................................................... 10
4.1.2.2 Root Certificate, Certificate Chain, and Trust Certificate...................................................................................... 12
4.1.2.3 Cross-Certificate..................................................................................................................................................... 14
4.1.2.4 CRL........................................................................................................................................................................ 15
4.1.2.5 CMPv2-based Certificate Management..................................................................................................................15
4.1.3 Certificate Management and Application Scenarios................................................................................................. 18
4.1.3.1 Certificate Preconfiguration Phase......................................................................................................................... 19
4.1.3.2 Certificate Management During Base Station Deployment................................................................................... 19
4.1.3.3 Certificate Management During Base Station Controller Deployment..................................................................21
4.1.3.4 Certificate Management During eCoordinator Deployment.................................................................................. 23
4.1.3.5 Certificate Management During the Operation Phase............................................................................................ 23
4.1.3.5.1 Certificate Application........................................................................................................................................ 23
4.1.3.5.2 Certificate Sharing............................................................................................................................................... 24
4.1.3.5.3 Certificate Validity Check................................................................................................................................... 26
Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. ii

SingleRAN
4.1.3.5.4 Certificate Update................................................................................................................................................27

4.1.3.5.5 Certificate Revocation......................................................................................................................................... 29
4.1.3.5.6 CRL Acquisition..................................................................................................................................................29
4.1.3.5.7 Offline Certificate Monitoring.............................................................................................................................30
4.1.3.6 Certificate Usage in UMPT+UMPT Cold Backup Mode...................................................................................... 32
4.1.3.7 Estimation of Certificate Reconfiguration Impact..................................................................................................32
4.1.3.8 Certificate Application of eCPRI Connections...................................................................................................... 33
4.1.3.9 IPv6 Certificate.......................................................................................................................................................34
4.2 Network Analysis......................................................................................................................................................... 34
4.2.1 Benefits...................................................................................................................................................................... 34
4.2.2 Impacts.......................................................................................................................................................................34
4.3 Requirements................................................................................................................................................................ 35
4.3.1 Licenses..................................................................................................................................................................... 35
4.3.2 Software.....................................................................................................................................................................36
4.3.2.1 GBFD-113526 BTS Supporting PKI......................................................................................................................36
4.3.2.2 WRFD-140210 NodeB PKI Support...................................................................................................................... 37
4.3.2.3 GBFD-160211 BSC Supporting PKI......................................................................................................................37
4.3.2.4 WRFD-160276 RNC Supporting PKI.................................................................................................................... 37
4.3.2.5 eCoordinator Supporting PKI................................................................................................................................. 37
4.3.2.6 LBFD-003010 Public Key Infrastructure (PKI)..................................................................................................... 38
4.3.2.7 MLBFD-12000312 Public Key Infrastructure (PKI)............................................................................................. 38
4.3.2.8 TDLBFD-003010 Public Key Infrastructure (PKI)................................................................................................38
4.3.2.9 FBFD-010023 Security Mechanism (PKI).............................................................................................................38
4.3.3 Hardware................................................................................................................................................................... 39
4.3.4 Others.........................................................................................................................................................................40
4.4 Operation and Maintenance..........................................................................................................................................40
4.4.1 When to Use.............................................................................................................................................................. 40
4.4.2 Precautions.................................................................................................................................................................40
4.4.3 Deployment of PKI on the GBTS/eGBTS/NodeB/eNodeB/gNodeB/Multimode Base Station............................... 42
4.4.3.1 Data Preparation..................................................................................................................................................... 42
4.4.3.2 Using MML Commands......................................................................................................................................... 52
4.4.3.3 Using the CME....................................................................................................................................................... 54
4.4.3.4 Activation Verification........................................................................................................................................... 58
4.4.4 Deployment of PKI on the eGBTS using a GTMUb.................................................................................................59
4.4.4.3 Using the CME....................................................................................................................................................... 64
4.4.5 Deployment of PKI on a NodeB Using a WMPT..................................................................................................... 64
4.4.5.3 Using the CME....................................................................................................................................................... 70
Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. iii

SingleRAN

4.4.6 Deployment of PKI on the Base Station Controller.................................................................................................. 70
4.4.6.3 Activation Observation...........................................................................................................................................81
4.4.7 Deployment of PKI on the eCoordinator...................................................................................................................83
4.4.7.3 Using the CME....................................................................................................................................................... 89
4.4.7.4 Activation Observation...........................................................................................................................................89
4.4.8 Deployment of PKI on a Board with eCPRI Ports.................................................................................................... 89
4.4.8.3 Using the CME....................................................................................................................................................... 90
4.4.9 Reconfiguration......................................................................................................................................................... 91
4.4.10 Network Monitoring................................................................................................................................................ 92
5 NE Supporting PKI Redundancy............................................................................................. 93

5.1 Principles...................................................................................................................................................................... 93
5.2 Network Analysis......................................................................................................................................................... 94
5.2.1 Benefits...................................................................................................................................................................... 94
5.2.2 Impacts.......................................................................................................................................................................94
5.3 Requirements................................................................................................................................................................ 95
5.3.1 Licenses..................................................................................................................................................................... 95
5.3.2 Software.....................................................................................................................................................................96
5.3.2.1 GBFD-160210 BTS Supporting PKI Redundancy.................................................................................................96
5.3.2.2 GBFD-160208 BSC Supporting PKI Redundancy................................................................................................ 96
5.3.2.3 WRFD-160275 NodeB Supporting PKI Redundancy............................................................................................96
5.3.2.4 WRFD-160277 RNC Supporting PKI Redundancy............................................................................................... 97
5.3.2.5 LOFD-070212 eNodeB Supporting PKI Redundancy........................................................................................... 97
5.3.2.6 MLOFD-070212 eNodeB Supporting PKI Redundancy........................................................................................97
5.3.2.7 TDLOFD-070212 eNodeB Supporting PKI Redundancy......................................................................................98
5.3.2.8 FBFD-010023 Security Mechanism (gNodeB Supporting PKI Redundancy).......................................................98
5.3.3 Hardware................................................................................................................................................................... 98
5.3.4 Networking................................................................................................................................................................ 98
5.4 Operation and Maintenance..........................................................................................................................................98
5.4.1 Precautions.................................................................................................................................................................98
5.4.2 Deployment of PKI Redundancy on the eGBTS/NodeB/eNodeB/gNodeB/Multimode Base Station......................99
5.4.2.2 Using MML Commands....................................................................................................................................... 100
5.4.2.3 Activation Observation.........................................................................................................................................101
Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. iv

SingleRAN
5.4.3 Reconstruction from a PKI-based Secure Network to a PKI Redundancy Network on the eGBTS/NodeB/eNodeB/
gNodeB/Multimode Base Station..................................................................................................................................... 102
5.4.3.1 Data Preparation................................................................................................................................................... 103
5.4.3.2 Data Configuration............................................................................................................................................... 104
5.4.4 Deployment of PKI Redundancy on the Base Station Controller........................................................................... 105
5.4.5 Reconstruction from a PKI-based Secure Network to a PKI Redundancy Network on the Base Station Controller
.......................................................................................................................................................................................... 106
5.4.5.2 Data Configuration............................................................................................................................................... 109
5.4.5.3 Activation Observation......................................................................................................................................... 110
6 NE Supporting Digital Certificate Whitelist Management...............................................111

6.1 Principles.....................................................................................................................................................................111
6.2 Network Analysis........................................................................................................................................................111
6.2.1 Benefits.................................................................................................................................................................... 111
6.2.2 Impacts.....................................................................................................................................................................112
6.3 Requirements.............................................................................................................................................................. 112
6.3.1 Licenses................................................................................................................................................................... 112
6.3.2 Software................................................................................................................................................................... 113
6.3.2.1 GBFD-181202 BTS Supporting Digital Certificate Whitelist Management........................................................113
6.3.2.2 WRFD-181220 NodeB Supporting Digital Certificate Whitelist Management...................................................113
6.3.2.3 LOFD-111203 eNodeB Supporting Digital Certificate Whitelist Management...................................................113
6.3.2.4 MLOFD-111203 eNodeB Supporting Digital Certificate Whitelist Management............................................... 114
6.3.2.5 FOFD-010080 IPsec (gNodeB Supporting Digital Certificate Whitelist Management)......................................114
6.3.3 Hardware..................................................................................................................................................................114
6.3.4 Others.......................................................................................................................................................................115
6.4 Operation and Maintenance........................................................................................................................................ 115
6.4.1 When to Use.............................................................................................................................................................115
6.4.2 Data Configuration.................................................................................................................................................. 115
6.4.2.3 Using the CME..................................................................................................................................................... 117
6.4.3 Activation Verification.............................................................................................................................................118
7 Parameters................................................................................................................................... 119
8 Counters...................................................................................................................................... 120
9 Glossary....................................................................................................................................... 121
Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. v

SingleRAN
10 Reference Documents............................................................................................................. 122
Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. vi

SingleRAN
PKI Feature Parameter Description 1 Change History
1 Change History
This chapter describes changes not included in the "Parameters", "Counters", "Glossary", and
"Reference Documents" chapters. These changes include:
l Technical changes
Changes in functions and their corresponding parameters
l Editorial changes
Improvements or revisions to the documentation
1.1 SRAN15.1 02 (2019-08-30)

This issue includes the following changes.
Technical Changes
Change Description Parameter Change
Turned off the RRU certificate request None

switch by default. For details, see 4.1.3.8
Certificate Application of eCPRI
Connections.
Editorial Changes
None
1.2 SRAN15.1 01 (2019-06-06)

This issue does not include any changes.
1.3 SRAN15.1 Draft B (2019-03-18)

This issue includes the following changes.
Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. 1

SingleRAN
Technical Changes
Added support of operator-issued device Added the RRUCERTREQSW parameter.

certificates by the boards with eCPRI
ports. For details, see:
4.1.2.1 Device Certificate
4.1.3.1 Certificate Preconfiguration
Phase
4.1.3.8 Certificate Application of
eCPRI Connections
4.4.2 Precautions
4.4.8 Deployment of PKI on a Board
with eCPRI Ports
Added the disuse statement for the None

MD5/DES/3DES/RSA1024/DH_768/
DH_1024 and SHA1 digital signature
algorithms. For details, see:
l 4.4.3.1 Data Preparation
Added support for NR by 3900 series None

base stations and DBS3900 LampSite.
For details, see:
l 4.3.3 Hardware
l 6.3.3 Hardware
Deleted the description of the built-in None

eCoordinator.
Editorial Changes
None
1.4 SRAN15.1 Draft A (2018-12-30)

This issue introduces the following changes to SRAN15.0 01 (2018-09-30).

SingleRAN
Technical Changes
Deleted the switch parameter in the Deleted the CERTCHKTSK.ISENABLE

certificate validity check task. parameter.
Editorial Changes
Reorganized this document using a new template.

SingleRAN
PKI Feature Parameter Description 2 About This Document
2 About This Document
2.1 General Statements

Purpose
Feature Parameter Description documents are intended to acquaint readers with:
l The technical principles of features and their related parameters
l The scenarios where these features are used, the benefits they provide, and the impact
they have on networks and functions
l Requirements of the operating environment that must be met before feature activation
l Parameter configuration required for feature activation, verification of feature activation,
and monitoring of feature performance
NOTE
This document only provides guidance for feature activation. Feature deployment and feature
gains depend on the specifics of the network scenario where the feature is deployed. To achieve
the desired gains, contact Huawei professional service engineers.
Software Interfaces
Any parameters, alarms, counters, or managed objects (MOs) described in Feature Parameter
Description documents apply only to the corresponding software release. For future software
releases, refer to the corresponding updated product documentation.
2.2 Applicable RAT

This document applies to GSM, UMTS, LTE FDD, LTE TDD, NB-IoT, and New Radio (NR).
For definitions of base stations described in this document, see section "Base Station
Products" in SRAN Networking and Evolution Overview.
2.3 Features in This Document

This document describes the following features.

SingleRAN
PKI Feature Parameter Description 2 About This Document
Feature ID Feature Name Section
LBFD-003010 Public Key Infrastructure (PKI) 4 PKI
TDLBFD-003010 Public Key Infrastructure (PKI)
MLBFD-12000312 Public Key Infrastructure (PKI)
FBFD-010023 Security Mechanism (PKI)
GBFD-113526 BTS Supporting PKI
GBFD-160211 BSC Supporting PKI
WRFD-140210 NodeB PKI Support
WRFD-160276 RNC Supporting PKI
GBFD-160210 BTS Supporting PKI Redundancy 5 NE Supporting PKI

Redundancy
GBFD-160208 BSC Supporting PKI Redundancy
WRFD-160275 NodeB Supporting PKI

Redundancy
WRFD-160277 RNC Supporting PKI Redundancy
LOFD-070212 eNodeB Supporting PKI

Redundancy
TDLOFD-070212 eNodeB Supporting PKI

Redundancy
MLOFD-070212 eNodeB Supporting PKI

Redundancy
FBFD-010023 Security Mechanism (gNodeB

Supporting PKI Redundancy)
GBFD-181202 BTS Supporting Digital Certificate 6 NE Supporting

Whitelist Management Digital Certificate
Whitelist
WRFD-181220 NodeB Supporting Digital Management
Certificate Whitelist Management
LOFD-111203 eNodeB Supporting Digital

MLOFD-111203 eNodeB Supporting Digital

FOFD-010080 IPsec (gNodeB Supporting Digital

Certificate Whitelist Management)

SingleRAN
PKI Feature Parameter Description 3 Overview
3 Overview
PKI is a security infrastructure that provides information security and digital certificate
management. It uses an asymmetric cryptographic algorithm to allow client and server
applications to trust each other's authentication credentials and perform authentication.
A digital certificate identifies a device and is created by a trusted certificate authority (CA),
which digitally signs the device information and public key. A digital certificate includes the
following information:
l Serial number and validity period of the certificate

l Organization that grants the certificate
l Public key
l Extension fields of the certificate
The SubjectAltName extension field in a digital certificate contains the base station's/
base station controller's/eCoordinator's identity information, such as the electronic serial
number (ESN) of the NodeB's main control board.
Asymmetric keys are used to authenticate equipment identities during digital certificate
authentication. The sender uses a private key to sign data, and the receiver uses a public key
in the certificate to verify signature validity. With digital certificates, both the receiver and the
sender confirm each other's identities to protect against communication fraud and
eavesdropping.
Huawei base stations/base station controllers/eCoordinators use a PKI-based end-to-end

certificate management solution. This solution facilitates the deployment and use of digital
certificates.
Each Huawei base station/base station controller is preconfigured with a device certificate on
its board issued by Huawei factory PKI system before delivery. You can view the certification
practice statement (CPS) of Huawei factory PKI system in the RootCA CPS.pdf document
obtained at http://support.huawei.com/support/pki. If operators deploy their own PKI
systems, Huawei recommends referring to the technical and management requirements of
Huawei factory PKI system in the document.
For Huawei products, digital certificates apply to the following scenarios:
l Authentication during the setup of an IPsec tunnel between a base station and an SeGW
on a radio bearer network. For details, see IPsec.

SingleRAN
PKI Feature Parameter Description 3 Overview
l Authentication during the setup of a Secure Sockets Layer (SSL) connection between an
eGBTS/NodeB/eNodeB/gNodeB/RNC/BSC/eCoordinator and the U2020 to protect data
transmission at the application layer. For details, see SSL.
l 802.1x-based access control for the eGBTS/NodeB/eNodeB/gNodeB, which uses digital
certificates for identity authentication. For details, see Access Control based on 802.1x.
l Setup of separate IPsec tunnels for each operator, thereby implementing secure service
isolation in RAN sharing scenarios when multiple operators share a base station and each
operator deploys a separate PKI server. For details, see Base Station Supporting Multi-
operator PKI.
Figure 3-1 Example of networking that uses digital certificates

SingleRAN
PKI Feature Parameter Description 4 PKI
4 PKI
4.1 Principles
4.1.1 PKI Architecture
4.1.1.1 Introduction
A PKI system manages digital certificates for network devices. This enables operators to
establish a trusted security domain so that they have a trust relationship with devices from
different vendors.
As shown in Figure 4-1, a PKI system on a wireless network generally consists of the
following network elements (NEs):
l NEs that use certificates, including the base station, base station controller, security
gateway (SeGW), and U2020.
l PKI server that manages certificates, including the CA, registration authority (RA), and
certificate & CRL database. CRL stands for certificate revocation list.
Figure 4-1 PKI system

SingleRAN
NOTE
For more information about PKI, see IETF RFC 5280 and IETF RFC 2585. Certificates and CRLs
comply with X.509v3 and X.509v2, respectively, but do not comply with earlier specifications. For
details, see IETF RFC 5280.
The eCoordinator cannot directly apply for or update certificates from the PKI system. The
eCoordinator's certificates must be manually maintained on the U2020.
4.1.1.2 CA
A CA serves as a central management node in a PKI system. As shown in Figure 4-1, a CA
manages certificates as follows:
l Approves or rejects certificate applications and issues certificates for approved
applications.
l Handles requests for certificate updates, verifications, revocations, and queries.
l Generates certificates and CRLs and publishes them in the certificate & CRL database.
On a live network, a CA system can use a layered structure to meet the requirements for CA
deployment across different areas. The root CA is not required to manage all certificates on
the entire network. The layered structure helps share the load of the root CA. Figure 4-2
shows an example of the CA system architecture.
Figure 4-2 Example of the CA system architecture
When building a PKI system, an operator determines the root CA domain based on the
operator's business scale and global network distribution.
l Root CA: The root CA is located at the top level and has the highest security and
reliability.
l Subordinate CA: Operators usually use the root CA to authorize important subordinate
CAs. CAs at each level can be authorized to sign and issue certificates for their lower-
level CAs or for end users. All certificates from end users to the root CA form a
certificate chain. As long as a user obtains the peer's root CA certificate and certificates
of subordinate CAs at different levels, the user can authenticate the certificates in the
certificate chain. This method facilitates certificate deployment because the root CA is
no longer required for signing and issuing certificates for all end users.

SingleRAN
l Cross-certification CA: issues a cross-certificate to a peer CA under another root CA

when a trust relationship must be set up with the peer CA.
l Device CA: issues digital certificates to network devices within its service scope.
There is no strict limitation imposed on the number of layers in a CA system. Operators can
divide the CA system into layers according to their requirements. Generally, a three-layer CA
system can meet the requirements of most operators. However, a two-layer CA system is
recommended, considering the management cost and complexity.
4.1.1.3 RA
An RA is a certificate registration and approval authority. As shown in Figure 4-1, an RA
interacts with communication entities such as base stations and base station controllers,
collects certificate applicants' information, and verifies their qualifications. The RA then
determines whether to issue a certificate to an applicant based on the verification result. If the
application is approved, the RA sends the application information to the CA which then issues
the certificate.
A CA incorporates the functions of an RA, thereby making the RA an optional component.

An RA is not required in a small-sized PKI system because the CA itself can handle
interactions with base stations and base station controllers. In a large-sized PKI system, the
CA focuses on certificate management and an RA takes over the functions of interacting with
base stations and base station controllers.
4.1.1.4 Certificate & CRL Database

As shown in Figure 4-1, a certificate & CRL database stores all certificates and the CRL
accessible to base stations/base station controllers/eCoordinators. Certificates are approved,
signed, and issued by CAs. The CRL records certificates revoked by CAs and can be obtained
by NEs from the operator's PKI system. The CRL enables base stations and base station
controllers to verify the certificates sent by the peer equipment (such as an SeGW), but the
base stations and base station controllers cannot verify their own certificates.
On a live network, a certificate & CRL database is an independent entity deployed on a server
in a demilitarized zone (DMZ). This allows users on the network to obtain certificates and
CRLs online, without imposing any security threat on the CA system.
A certificate & CRL database is generally deployed on an FTP server or Lightweight

Directory Access Protocol (LDAP) server.
4.1.2 Certificates and Files Used by NEs
4.1.2.1 Device Certificate

Device certificates are used to authenticate the identities of NEs. Each device certificate has a
private-public key pair. The key pair is used to compute digital signatures during
authentication between a base station/base station controller/eCoordinator and an SeGW or
the U2020.
Device certificates used by base stations/base station controllers/eCoordinators are Huawei-

issued device certificates and operator-issued device certificates.

SingleRAN
Huawei-Issued Device Certificate

Huawei-issued device certificates are used in the following scenarios:
l Each Huawei base station is preconfigured with a Huawei-issued device certificate
before delivery. The certificate is stored on the main control board (UMPT/LMPT/
UMDU/MDUC/GTMUc/SMPT/UEFU), BBP board, or UTRPc board. The certificate is
bound with the ESN of the board.
Boards with eCPRI ports are preconfigured with Huawei-issued device certificates
before delivery. The certificates can be replaced with operator-issued device certificates.
The key of a Huawei-issued device certificate is 2048 bits long. Huawei-issued device
certificates are named appcert.pem and are activated before base station delivery.
NOTE
l The Huawei-issued device certificate preconfigured on the GTMUc in a GBTS can only be
used for SSL connections between the GBTS and the site maintenance terminal (SMT). It
cannot be used for PKI or IPsec authentication.
l The Huawei-issued device certificate preconfigured on the GTMUc in an eGBTS can only be
used for PKI and SSL authentication. It cannot be used for IPsec authentication.
l Each Huawei base station controller is preconfigured with a Huawei-issued device
certificate before delivery. The certificate is bound with the ESN of the OMU board and
is named hwusercert.pem. The key of a Huawei-issued device certificate is 2048 bits
long. Huawei-issued device certificates for base station controllers are activated before
base station controller delivery.
l All Huawei eCoordinators are preconfigured with the same certificate issued by Huawei
CA before delivery. The certificate is stored on the OMU board. The certificate
preconfigured on an eCoordinator, in a strict sense, is not a device certificate because it
is not bound with the ESN of the OMU. If the preconfigured certificate on one Huawei
eCoordinator is cracked, the preconfigured certificates on all Huawei eCoordinators are
cracked. Therefore, it is recommended that an operator-issued device certificate be
applied for an eCoordinator after the eCoordinator connects to a network.
The application scenarios of Huawei-issued device certificates are as follows:
l If a PKI system is deployed in an operator's network, Huawei-issued device certificates
are used for authentication during the operator-issued device certificate application
process.
– When a base station/base station controller accesses the operator's network, it
applies for a device certificate from the operator's CA by sending a CMPv2
message. The operator-issued device certificate is then used for authentication
during the subsequent communication process.
– When an eCoordinator accesses the operator's network, a device certificate must be
manually applied for from the operator's CA through the U2020. The operator-
issued device certificate is then used for authentication during the subsequent
communication process.
l If no PKI system is deployed in an operator's network, the peer equipment of a base
station/base station controller/eCoordinator can be preconfigured with the Huawei root
certificate. Huawei-issued device certificates are used for authentication between the
base station/base station controller/eCoordinator and peer equipment.
If the preconfigured Huawei-issued device certificate of a base station/base station controller/
eCoordinator is lost (the base station uses a UMPT/UMDU/MDUC as the main control board
or uses a UTRPc as the transmission board), the base station reports ALM-26841 Certificate

SingleRAN
Invalid or the base station controller/eCoordinator reports ALM-20851 Digital Certificate

Loss, Expiry, or Damage. Based on the Certificate Name parameter in the alarm parameters,
determine whether the preconfigured Huawei-issued device certificate is lost.
l If the preconfigured Huawei-issued device certificate of a base station is lost and this
certificate is required for identity authentication, contact Huawei technical support
engineers to replace the board.
l If the preconfigured Huawei-issued device certificate hwusercert.pem of a base station
controller/eCoordinator is lost and this certificate is required for identity authentication,
contact Huawei technical support engineers to replace the board. The device certificate
usercert.pem is preconfigured by software and is not bound with the ESN of the OMU
board. If such a certificate is lost, contact Huawei technical support engineers to reinstall
software.
If a base station is not configured with a UMPT/UMDU/MDUC/UTRPc, run the DSP
CERTMK command to query the status of the preconfigured device certificate.
Regardless of whether a PKI system is deployed in the operator's network, if Huawei-issued
device certificates are used for authentication during all communication processes, the
following security risks exist:
l Huawei-issued device certificates have a validity period of 15 years.
l You cannot update, apply for, or revoke Huawei-issued device certificates.
l Huawei-issued device certificates may be disclosed if they are used online for a long
period of time.
Operator-Issued Device Certificate

If a PKI system is deployed in an operator's network, Huawei-issued device certificates are
used for authentication during the operator-issued device certificate application process. The
operator-issued device certificate is then used for authentication during the subsequent
communication process.
The validity periods of operator-issued device certificates are configured by operators.
Operator-issued device certificates can be applied for, updated, and revoked. Compared with
Huawei-issued device certificates, operator-issued device certificates feature flexible
management and various risk control methods. It is recommended that the Huawei-issued
device certificate be replaced with an operator-issued device certificate immediately after the
base station/base station controller/eCoordinator connects to the operator's network.
4.1.2.2 Root Certificate, Certificate Chain, and Trust Certificate
Root Certificate
A root certificate is the certificate of the root CA and is used to verify the validity of device
certificates issued by the root CA.
The Huawei root certificate is preconfigured in each Huawei base station as the trust
certificate before delivery. The certificate is stored on the main control board (UMPT/LMPT/
UMDU/GTMUc), baseband processing unit, or UTRPc board and can be used to verify
Huawei-issued device certificates. The Huawei root certificate is named caroot.pem.
The Huawei root certificate is preconfigured on each Huawei base station controller/
eCoordinator as the trust certificate before delivery. The certificate can be used to verify
Huawei-issued device certificates and is named rootca.pem.

SingleRAN
NOTE
Huawei wireless-network CA system is a 2-layer CA system. caroot.pem and rootca.pem are files in
the 2-layer certificate chain.
If a Huawei base station/base station controller/eCoordinator uses an operator-issued device

certificate to connect to an operator's network, the base station/base station controller/
eCoordinator must be preconfigured with the operator's root certificate or certificate chain to
authenticate the operator's device, such as an SeGW or a third-party FTP server. The
operator's device must be preconfigured with and trust the operator's root certificate or
certificate chain to authenticate the base station/base station controller/eCoordinator. During
authentication, the communicating parties use their respective trust certificates to verify the
validity of the peer's device certificate.
Figure 4-3 shows an example of how a CA uses the Huawei root certificate to authenticate a
Huawei-issued device certificate. The CA is preconfigured with the Huawei root certificate.
During authentication, a base station sends its Huawei-issued device certificate to the CA
which then uses the Huawei root certificate to verify the device certificate.
Figure 4-3 Base station authentication by a CA
If the preconfigured Huawei root certificate of a base station/base station controller/

eCoordinator is lost (the base station uses a UMPT/UMDU/MDUC as the main control board
or uses a UTRPc as the transmission board), the base station reports ALM-26841 Certificate
Invalid or the base station controller/eCoordinator reports ALM-20851 Digital Certificate
Loss, Expiry, or Damage. Based on the Certificate Name parameter in the alarm parameters,
determine whether the preconfigured Huawei root certificate is lost. If the preconfigured
Huawei root certificate is lost and this certificate is required for authentication, contact
Huawei technical support engineers to replace the board.
If a base station neither uses a UMPT/UMDU/MDUC as the main control board nor uses a
UTRPc as the transmission board, run the DSP TRUSTCERT command to query the status
of the preconfigured root certificate.
Certificate Chain
If there are multiple layers of CAs in a PKI system, certificates of the CAs form a certificate
chain, which is used to verify the validity of device certificates issued by the bottom-level CA
in the chain.

SingleRAN
If there is a certificate chain from the base station's device certificate up to the root CA, the
peer device must be preconfigured with the certificate chain so that the peer device can verify
the validity of the device certificate sent by the base station during Internet Key Exchange
(IKE) authentication.
Trust Certificate
A trust certificate is the root certificate or certificate chain that is loaded on NEs.
A base station/base station controller/eCoordinator reloads the device certificate and verifies
its validity each time the base station/base station controller/eCoordinator restarts.
4.1.2.3 Cross-Certificate
A cross-certificate is issued by one CA to another in order to establish a trust relationship
between them. The eGBTS, NodeB, eNodeB, and gNodeB support cross-certificates, whereas
the GBTS, RNC/BSC, and eCoordinator do not.
Cross-certification is a process in which two devices use the cross-certificate for

authentication. Figure 4-4 shows the procedure for cross-certification.
Figure 4-4 Procedure for cross-certification

SingleRAN
Before using the cross-certificate for authentication, the operator's CA and the Huawei CA
must issue a cross-certificate to each other. This is a cumbersome procedure and hence is not
recommended.
4.1.2.4 CRL
CRL is used to verify the validity of the peer certificate. Certificates need to be revoked when
they are disclosed or when devices that use the certificates are replaced or discarded.
Revoked certificates are recorded in a CRL. An NE uses a CRL to check the validity of the
certificate sent by a peer device when authenticating the peer device. The peer device is not
trustworthy if its certificate is recorded in a CRL.
l O&M personnel can run the SET BTSCRLPOLICY command to set a CRL usage
policy for the GBTS.
l O&M personnel can run the SET CRLPOLICY command to set a CRL usage policy
for the eGBTS/NodeB/eNodeB/gNodeB/eCoordinator/base station controller.
The settings of the CRLPOLICY.CRLPOLICY (for the eGBTS/NodeB/eNodeB/gNodeB) or
BTSCRLPOLICY.CRLPOLICY parameter (for the GBTS) are as follows:
l If the parameter is set to NOVERIFY, the base station/base station controller/
eCoordinator does not perform CRL-based certificate validity checks.
l If the parameter is set to ALARM, the base station reports ALM-26832 Peer Certificate
Expiry and the base station controller/eCoordinator reports ALM-20854 Peer Certificate
Invalid, Expiry, or Damage when the peer's device certificate is detected in the CRL.
l If the parameters are set to DISCONNECT, the base station/base station controller/
eCoordinator reports the preceding alarms and disconnects the communication with the
peer end when the peer's device certificate is detected in the CRL.
4.1.2.5 CMPv2-based Certificate Management

On secure networks, the base station/base station controller can automatically apply for
operator-issued device certificates and update certificates using CMPv2. The eCoordinator
does not support CMPv2-based certificate management.
CMPv2 complies with IETF RFC 4210, IETF RFC 4211, and draft-ietf-pkix-cmp-transport-
protocols-07. The base station/base station controller/U2020 uses Hypertext Transfer
Protocol/Hypertext Transfer Protocol Secure (HTTP/HTTPS) as the bearer protocol for
CMPv2. Figure 4-5 shows the transport protocol stack for CMPv2.
Figure 4-5 Transport protocol stack for CMPv2

SingleRAN
Figure 4-6 shows the topology for managing certificates in base stations and base station
controllers based on CMPv2.
Figure 4-6 Example topology for CMPv2-based certificate management
As shown in Figure 4-6, base stations or base station controllers communicate with the
operator's PKI server for CMPv2-based certificate management. The PKI server can be a CA,
RA, or certificate & CRL database.
When the base stations or base station controllers apply for operator-issued device certificates
for the first time, the operator's CA is preconfigured with the Huawei root certificate. The root
certificate is used to verify Huawei-issued device certificates carried in CMPv2 messages sent
by the base stations or base station controllers. The operator's CA also includes operator-
issued device certificates and root certificates or certificate chains in CMPv2 response
messages sent to the base stations or base station controllers.
When the base stations or base station controllers update certificates, the operator's CA and
the base stations or base station controllers authenticate each other using operator-issued
device certificates and operator's root certificates or certificate chains. In this case, Huawei-
issued device certificates and Huawei root certificates are no longer used.
Figure 4-7 shows how a base station or base station controller applies for a certificate based
on CMPv2.

SingleRAN
Figure 4-7 Certificate application process for a base station or base station controller
NOTE
After sending a CMPv2-based certificate request message, the base station waits for a response from the
CA. The waiting timeout interval is 60s in single-operator PKI scenarios and 20s for each PKI in multi-
operator PKI scenarios. If the base station does not receive any response from the CA before the waiting
timeout interval elapses, the certificate application fails.
In step 2, the message contains information such as the generated public key, SubjectName
field of the certificate, alternative SubjectName field of the certificate, certificate signature
algorithm, and Huawei-issued device certificate.
l The SubjectName field in the certificate request message contains the Common Name
field. Some CAs require that the Common Name field in certificate request messages be
the same as that in Huawei-issued device certificate. If they are not the same, these CAs
will not issue device certificates (also known as operator-issued device certificates).
l In Huawei-issued device certificates preconfigured on some LMPT boards, the Common
Name field uses the format of ESN+space+eNodeB. In this case, to meet the preceding
CA requirement, a space is automatically added to the Common Name field in the
certificate request message if the values of the CERTREQ.COMMNAME and
CERTREQ.USERADDINFO parameters are ESN and eNodeB, respectively. In this
way, the Common Name field in the message is in the format of ESN+space+eNodeB.

SingleRAN
If the CERTREQ.LOCALNAME parameter is not specified, the DNSName field in the

backup SubjectName field also uses the format of ESN+space+eNodeB.
Figure 4-8 shows how a base station or base station controller updates its certificate based on
CMPv2.
Figure 4-8 CMPv2-based certificate update process for a base station or base station
controller
In step 2, the key update request message is also the certificate update request. This message
includes the new public key and the operator-issued device certificate to be updated.
In step 5, the CA uses the public key of the operator-issued device certificate carried in the
key update request message to verify the signature in the message. In addition, the CA uses
the operator's root certificate or certificate chain to verify the operator-issued device
certificate.
For details about the structure of a CMPv2 message and the process of exchanging CMPv2
messages, see IETF RFC 4210 and IETF RFC 4211.
4.1.3 Certificate Management and Application Scenarios

SingleRAN
4.1.3.1 Certificate Preconfiguration Phase

The certificate preconfiguration phase includes the following activities:
l Each of the following boards is configured with a Huawei root certificate and a Huawei-
issued device certificate:
– Main control board or UTRPc of a base station
– OMU board of a base station controller/eCoordinator
NOTE
Each Huawei eCoordinator is preconfigured with a Huawei-issued device certificate before

delivery. The certificate is not bound with the ESN of the OMU board. That is, all Huawei
eCoordinators are preconfigured with the same Huawei-issued device certificate before
delivery.
– Board with an eCPRI port
l Publication of the Huawei root certificate and CRLs
The Huawei root certificate and CRLs are published at http://support.huawei.com/
support/pki by using a web server or a Universal Serial Bus (USB) flash drive.
4.1.3.2 Certificate Management During Base Station Deployment

Each Huawei base station is preconfigured with a Huawei-issued device certificate on its
board before delivery. To connect to an operator's network deployed with a PKI system, the
Huawei base station must apply for an operator-issued device certificate during base station
deployment.
This section describes a scenario where IPsec is used and digital certificates are used for
authentication. Figure 4-9 shows such an example.
Figure 4-9 Example of automatic base station deployment in IPsec networking
Figure 4-10 shows the certificate application procedure during automatic base station
deployment.

SingleRAN
Figure 4-10 Certificate application procedure during automatic base station deployment
During automatic base station deployment, the Huawei-issued device certificate

preconfigured on the base station is used as follows:
l If the base station has obtained CA information from the DHCP server or USB flash
drive, the operator requires the base station to use an operator-issued device certificate
for authentication. The CA information includes the IP address of the CA and is used to
obtain certificates.
– If the base station has a valid operator-issued device certificate, the base station
directly uses this certificate.
– If the base station has an operator-issued device certificate but information about
the issuer is inconsistent with the CA information, this certificate is considered

SingleRAN
invalid and cannot be used. If the CERTCHKTSK.AUTOREAPPLYSW parameter

is set to ON, the base station uses the preconfigured Huawei-issued device
certificate to apply for a new operator-issued device certificate.
– If the base station fails to obtain the operator-issued device certificate or if the
request for the device certificate times out, the base station uses the preconfigured
Huawei-issued device certificate. If the base station cannot be automatically
deployed by using the Huawei-issued device certificate, it restarts and attempts to
obtain the operator-issued device certificate again.
l If CA information fails to be obtained during base station deployment, the base station
uses the preconfigured Huawei-issued device certificate.
NOTE
l If an operator's network is deployed with a PKI system, it is recommended that the same operator-
issued device certificate be used for IPsec authentication, SSL authentication, and 802.1x-based
access control.
l During automatic base station deployment by plug and play (PnP), only Huawei-issued device
certificates can be used for authentication during 802.1x-based access control.
l By default, the same certificate is used for 802.1x-based access control and SSL authentication in
the operation phase.
l The name of the operator-issued device certificate used by a base station during base station
deployment must be OPKIDevCert.cer.
4.1.3.3 Certificate Management During Base Station Controller Deployment

To connect to an operator's network deployed with a PKI system, the Huawei base station
controller must apply for a device certificate from the operator's CA. The operator-issued
device certificate can be applied for using a CMPv2-based certificate application procedure or
in manual mode depending on the type of preconfigured Huawei-issued device certificate.
Figure 4-11 shows a base station controller deployment procedure.

SingleRAN
Figure 4-11 Base station controller deployment procedure
A CMPv2-based certificate application procedure is triggered by the REQ DEVCERT

command. Figure 4-12 shows a manual certification application procedure.
Figure 4-12 Manual certificate application procedure

SingleRAN
For details about CMPv2-based and manual certification application procedures, see 5.4.4.2
Using MML Commands.
4.1.3.4 Certificate Management During eCoordinator Deployment

The eCoordinator does not support CMPv2. During eCoordinator deployment, an operator-
issued device certificate must be applied for through the U2020.
When certificates for an eCoordinator can be independently configured and managed, an SSL
connection must be established between the eCoordinator and the U2020 using the Huawei-
issued device certificate, and then an operator-issued device certificate must be manually
applied for through the U2020, as illustrated in Figure 4-13.
Figure 4-13 Manual certificate application procedure
For details about the manual certificate application procedure, see 5.4.4 Deployment of PKI
Redundancy on the Base Station Controller.
4.1.3.5 Certificate Management During the Operation Phase
4.1.3.5.1 Certificate Application

For details about how to apply for a certificate for the base station controller, see 4.1.3.3
Certificate Management During Base Station Controller Deployment. For details about
how to apply for a certificate for the eCoordinator, see 4.1.3.4 Certificate Management
During eCoordinator Deployment.
In the operation phase, if a base station needs to use an operator-issued device certificate for
IKE authentication but it does not have such a certificate, the base station must apply for an
operator-issued device certificate from the operator's CA based on CMPv2.
CMPv2-based certificate application of base stations is triggered in two modes:
l Manual mode
To manually trigger the application, O&M personnel can configure information such as
the certificate deployment location, CA, trust certificate, and certificate request on the
base station, and then run the REQ DEVCERT command to trigger a CMPv2-based
certificate application procedure. After this command is executed, the base station
reports the progress of the certificate application. If an operator-issued device certificate

SingleRAN
is obtained, O&M personnel can run the MOD APPCERT command to change the
active certificate to the operator-issued device certificate.
To ensure that the device certificate can be used to successfully establish security
channels between the base station and the peer end, it is recommended that the TST
APPCERT command be executed to check whether the operator-issued device
certificate can be used for IKE and SSL connections before running the MOD
APPCERT command. Then, run the CFM CB command to enable automatic
configuration data rollback. For details, see the CFM CB command help.
l Automatic mode
The base station obtains information about the certificate deployment location, CA,
certificate request, and active certificate from the configuration file. After the base
station restarts, it automatically triggers a CMPv2-based certificate application procedure
based on CA information. If the application fails, the base station automatically
reinitiates a CMPv2-based certificate application procedure.
NOTE
After the IKE negotiation succeeds, the base station starts checking the IKE negotiation status
every 7 minutes. If an IKE negotiation fails and digital certificates are used for identity
authentication, the base station checks the digital certificates used for the IKE negotiation. If a
digital certificate is abnormal (for example, the digital certificate has been revoked or expired, the
certificate file does not exist, or the digital certificate issuer information differs from the CA
information), a certificate application procedure is automatically triggered.
For the CMPv2-based certificate application procedure, see 4.1.2.5 CMPv2-based

Certificate Management.
NOTE
Base stations cannot apply for certificates through E1/T1 ports.
4.1.3.5.2 Certificate Sharing
Base Station
The certificate that is applied for during base station deployment is configured on the board
that connects the base station to the transport network. SSL authentication applies only to the
main control board of a base station. If no certificate is deployed on the main control board
for SSL authentication, the main control board must share the certificate with the board that
connects the base station to the transport network.
Certificate sharing applies to the following scenarios:
l A certificate is deployed on a UTRPc board of a single-mode base station, and the main
control board shares the certificate with the UTRPc board. As indicated by (1) in Figure
4-14, the WMPT board shares the certificate with the UTRPc board.
l In a separate-MPT multimode base station using co-transmission, a certificate is
deployed on the main control board connecting to the transport network and is shared
between this main control board and the main control boards of other RATs. As indicated
by (2) in Figure 4-14, a certificate is deployed on the UMPT_L board and shared
between the UMPT_U and UMPT_L boards.
l In a separate-MPT multimode base station using co-transmission, a certificate is
deployed on a UTRPc board, and the main control boards share the certificate with the
UTRPc board. As indicated by (3) in Figure 4-14, the UMPT_U and UMPT_L boards
share the certificate with the UTRPc board.

SingleRAN
Figure 4-14 Examples of certificate sharing
When a base station uses certificate sharing, the following parameters must be set:
l CERTDEPLOY.DEPLOYTYPE (for the eGBTS/NodeB/eNodeB/gNodeB)
l BTSCERTDEPLOY.DEPLOYTYPE (for the GBTS)
Set these parameters to SPECIFIC.
Base station certificate sharing has the following restrictions:
l Only active certificates can be shared. For example, SSL certificates, root certificates,
and CRLs can be shared.
l Huawei base stations support certificate sharing only in backplane interconnection and
BBU interconnection scenarios but do not support this function in panel interconnection
scenarios.
l BBU3910As do not support certificate sharing.
Base Station Controller/eCoordinator

If the base station controller/eCoordinator uses the ESN of the active OMU board to apply for
a digital certificate during base station controller/eCoordinator deployment and the standby
OMU board or SAU board (only configured in a base station controller) needs to use the
digital certificate, the standby OMU board or SAU board must obtain the digital certificate
from the active OMU board.
During base station controller deployment, use the ESN of the active OMU board to apply for
a digital certificate. If the active OMU board becomes faulty and is removed, use the ESN of a
functional OMU board to apply for a new digital certificate.
Certificate sharing needs to be performed when:

SingleRAN
l Active and standby OMU boards are switched over. The currently active OMU board can
use the digital certificate on the previously active OMU board to set up an SSL
connection with the U2020.
l The SAU board needs the digital certificate on the active OMU board to set up an SSL
connection with the Nastar. This scenario can occur only for base station controllers.
4.1.3.5.3 Certificate Validity Check

If an expired certificate is not updated, a base station/base station controller/eCoordinator that
uses the certificate cannot be authenticated to access the operator's network. To prevent this
problem, base stations/base station controllers/eCoordinators periodically check the validity
periods of certificates. The CERTCHKTSK.PERIOD parameter specifies the interval
between two consecutive certificate validity checks. The base station/base station controller/
eCoordinator periodically checks certificate validity as follows:
l Upon detecting that the period remaining until a certificate expires is less than the value
of the CERTCHKTSK.ALMRNG parameter, the base station/base station controller/
eCoordinator determines that the certificate is about to expire.
l Upon detecting that the expiration time of a certificate is earlier than the current time, the
base station/base station controller/eCoordinator determines that the certificate has
expired.
Table 4-1 describes the processing performed by the base station/base station controller/
eCoordinator when it detects that the device certificate is abnormal.
Table 4-1 Processing performed when a device certificate detected abnormal
Certificate Certificate Value of Processing

Validity Is in Use or CERTCHKT
Status Not SK.UPDAT
EMETHOD
Is about to In use CMP The base station/base station controller

expire automatically triggers a CMPv2-based
certificate update procedure. If the
certificate update fails, the base station
reports ALM-26842 Automatic
Certificate Update Failed or the base
station controller reports ALM-20803
Certificate Auto-update Failed.
Subsequently, if the certificate has been
successfully updated or the
corresponding CERTMK managed
object (MO) has been deleted, the alarm
is cleared.
In use MANUAL The base station reports ALM-26840

Imminent Certificate Expiry or the base
station controller/eCoordinator reports
ALM-20850 Digital Certificate Will Be
out of Valid Time. Subsequently, if the
certificate has been updated or the

SingleRAN
Certificate Certificate Value of Processing

Validity Is in Use or CERTCHKT
Status Not SK.UPDAT
EMETHOD
Not in use N/A corresponding CERTMK MO has been

deleted, the alarm is cleared.
Expired N/A N/A The base station reports ALM-26841

Certificate Invalid or the base station
controller/eCoordinator reports
ALM-20851 Digital Certificate Loss,
Expiry, or Damage, instructing the
O&M personnel to determine the cause
and update the certificate as soon as
possible. Subsequently, if the certificate
has been updated or the corresponding
CERTMK MO has been deleted, the
alarm is cleared.
NOTE
l You can specify the device certificate to be used through

1. The MOD APPCERT command
2. The certificate source in the ADD IKEPEER command
l Certificate validity checks require that the system time of the base station/base station controller/
eCoordinator be valid. Alarms may fail to be reported if the system time is invalid. If the system
time is invalid (for example, ALM-26266 Time Synchronization Failure is reported), the certificate
status on the base station/base station controller/eCoordinator may be displayed as normal by
default.
l Each time a base station is reset, a certificate validity check task is added to immediately check
certificate validity. If the certificate is about to expire, the base station triggers an automatic
certificate update procedure.
4.1.3.5.4 Certificate Update

Certificates used by base stations/base station controllers/eCoordinators are Huawei-issued
device certificates and operator-issued device certificates. This section only describes how to
update operator-issued device certificates. Huawei-issued device certificates do not need to be
updated because:
l Huawei-issued device certificates are used to ensure security during certificate
application.
l Generally, Huawei-issued device certificates are used only during base station/base
station controller/eCoordinator deployment.
l The lifecycle of Huawei-issued device certificates is usually longer than that of the
devices.
Certificate Update Scenarios

A certificate used by a base station/base station controller/eCoordinator must be updated in
the following scenarios:

SingleRAN
l The certificate is about to expire.

l Base station/base station controller/eCoordinator information, such as the time and
location, has changed.
Certificate Update of the Base Station and Base Station Controller

A certificate update is triggered on the base station/base station controller in two modes:
l Automatic mode
A task of periodically checking the certificate validity is configured on the base station/
base station controller with the CERTCHKTSK.UPDATEMETHOD (for the eGBTS/
NodeB/eNodeB/gNodeB)/BTSCERTCHKTSK.UPDATEMETHOD (for the GBTS)
parameter set to CMP. Upon detecting that a certificate is about to expire, the base
station or base station controller automatically triggers a CMPv2-based certificate
update. In automatic mode, a private-public key pair is also automatically updated during
the certificate update.
NOTE
During an automatic certificate update procedure, if the certificate update fails due to intermittent
transmission or network congestion, the system automatically retries certificate update for at most
twice with an interval of 10 minutes.
l Manual mode
O&M personnel can run the UPD DEVCERT command to manually trigger a CMPv2-
based certificate update. In this command, the CERTMK.APPCERT parameter
specifies a certificate to be updated, the REKEY parameter specifies whether to update a
private-public key pair, and the CERTREQ.KEYSIZE parameter specifies a key length.
After this command is executed, the base station or base station controller reports the
progress of the certificate update.
During the certificate update, the base station or base station controller automatically
configures a new certificate and tests it. If the configuration or test of the new certificate fails,
the base station reports ALM-26842 Automatic Certificate Update Failed or the base station
controller reports ALM-20803 Certificate Auto-update Failed. In this scenario, the original
certificate will be used until a successful certificate update occurs.
In IPsec scenarios, a new certificate is tested by using the certificate for authentication during
IKE renegotiation. In SSL scenarios, a new certificate is tested by using the certificate for
authentication during SSL reconnection. If the IKE renegotiation or SSL reconnection fails,
the base station uses the original certificate. The base station controller only supports the SSL
scenarios. If SSL reconnection fails, the base station controller uses the original certificate.
Bidirectional authentication is used for SSL certificate testing. That is, the NE and U2020
authenticate the device certificates of each other. The SSL certificate testing result reflects
whether the certificates can be used.
Certificate Update of the eCoordinator

When certificates for an eCoordinator can be independently configured and managed, the
procedure for certificate update is as follows:
1. Run the SET CERTCHKTSK command to set a periodic certificate validity check task.
2. The eCoordinator does not support CMPv2. When the eCoordinator reports a certificate
expiry alarm, the certificate needs to be manually updated. The manual update procedure

SingleRAN
is the same as a certificate application procedure. For details, see 4.1.3.4 Certificate
Management During eCoordinator Deployment.
4.1.3.5.5 Certificate Revocation

If a base station/base station controller/eCoordinator is no longer used or the private key of its
device certificate is disclosed or cracked before the certificate expires, the certificate must be
revoked to prevent illegal use of the certificate. Currently, the base station/base station
controller/eCoordinator does not support online certificate revocation. Certificates must be
manually revoked. Figure 4-15 shows the base station's certificate revocation process. The
base station controller's/eCoordinator's certificate revocation process is identical to this
process.
Figure 4-15 Base station's certificate revocation process
If the base station finds that the operator-issued device certificate was revoked based on the
CRL file, the base station initiates a certificate application procedure. If the base station is
discarded, the certificate application request will be rejected by the CA and no new device
certificate will be issued.
4.1.3.5.6 CRL Acquisition

A base station/base station controller/eCoordinator periodically obtains CRLs from the
certificate & CRL database. The CRLs are used to verify the validity of the certificate of the
peer device.
Table 4-2 lists the methods to obtain CRLs.
Table 4-2 Methods to obtain CRLs

Mode Method to Obtain Type of CRL Supported By
CRLs Server
Manual Users run MML FTP server Base station/base

commands to enable the station controller/
base station or base eCoordinator
station controller to
obtain the CRLs from the
FTP server.
Automatic Scheduled tasks are LDAP server Base station/base

configured so that CRLs station controller

SingleRAN
Mode Method to Obtain Type of CRL Supported By

CRLs Server
can be automatically FTP server Base station/base

obtained. station controller/
eCoordinator
To enable the base station/base station controller/eCoordinator to automatically obtain CRLs,

set CRLTSK.IP to the IP address of the CRL server and set CRLTSK.CRLGETMETHOD
to the method of obtaining CRLs. In addition, if the LDAP server is used, set
CRLTSK.SEARCHDN and CRLTSK.PORT to specify the name of the LDAP server and
the port number. The CRLTSK.ISCRLTIME parameter specifies whether to automatically
download CRLs after a CRL update period (specified by the CRLTSK.PERIOD parameter)
has elapsed.
The CRL can be obtained by using SSL-protected transmission mode:
l If the CRL is obtained using LDAP, set the following parameters:
– CRLTSK.CONNMODE
– CRLTSK.AUTHPEER. If the CRLTSK.AUTHPEER parameter is set to
ENABLE, ensure that both the base station/base station controller and the CRL
server are configured with the peer device certificate and the peer CA trust
certificate.
NOTE
If the CRL is obtained using LDAP and the base station/base station controller supports only
LDAPv3, the CRL server must support LDAPv3. For details, see IETF RFC 4511 Lightweight
Directory Access Protocol (LDAP).
l If the CRL is obtained using FTP over SSL (FTPS), set FTPCLT.ENCRYMODE (for
the eGBTS/NodeB/eNodeB/gNodeB) or FTPSCLT.ENCRYMODE (for the GBTS/
GBSC/RNC/eCoordinator) to AUTO(Auto) or ENCRYPTED(SSL Encrypted), and
enable the FTPS function on the CRL server side. If this parameter is set to
ENCRYPTED(SSL Encrypted), ensure that all FTP servers communicating with the
base station/base station controller/eCoordinator support FTPS.
If the CRL server needs to be authenticated, set the FTPCLT.SSLCERTAUTH (for the
eGBTS/NodeB/eNodeB/gNodeB) or FTPSCLT.SSLCERTAUTH (for the GBTS/
GBSC/RNC/eCoordinator) parameter to YES(Yes). In addition, ensure that the base
station/base station controller/eCoordinator has been configured with the peer CA trust
certificate and the CRL server has been configured with a device certificate.
4.1.3.5.7 Offline Certificate Monitoring

If a board leaves the customer's network due to board repair or retirement, the certificate and
private key on the board may be disclosed. Therefore, the offline certificate monitoring
function is required. This function allows users to use the U2020 to query and export basic
information about abnormal certificates, including the base station name, certificate issuer
name, certificate serial number, status, and time when the certificate is detected abnormal.
Currently, this function can take effect only for offline certificates on base stations.
NOTE
Basic information about abnormal certificates will be saved on the U2020 for 30 days and then be
automatically removed. The purpose is to avoid repeated exporting of certificate information.

SingleRAN
The status of a certificate may be abnormal in the following conditions:

l The certificate does not exist, for example, when the board is returned for repair.
l The U2020 deletes the NE where the certificate is deployed.
l The U2020 cannot communicate with the NE, where the certificate is deployed, for a
long time (for example, when the NE leaves the network).
l The certificate is deleted manually. The operator needs to ensure that a manually deleted
certificate has been revoked by the CA. The information about a deleted certificate will
be saved on the U2020 for a period. After the period expires, the information is
automatically deleted.
Figure 4-16 shows the principle of offline certificate monitoring.
Figure 4-16 Principle of offline certificate monitoring
In the following scenarios, the device certificate on the base station does not need to be
revoked although the device certificate status is abnormal on the U2020:
l The base station operates normally but cannot communicate with the U2020 for a long
time.
l The base station or its board is transferred to another U2020 for management. In this
case, the device certificate of the base station or board is recorded as abnormal on the
original U2020.
l The value of CERTDEPLOY.DEPLOYTYPE is changed to NULL, which indicates
that the device certificate on the base station is not applied. In this situation, the
certificate status on the U2020 is that the certificate does not exist.
If the certificate must be revoked, you need to manually run the certificate revocation
command on the CA.
The offline certificate monitoring function cannot be used in the following conditions:
l This function does not take effect for the preconfigured Huawei-issued device
certificates. The name of the issuer of the preconfigured Huawei-issued device
certificates starts with "Huawei". Therefore, it is not recommended that the name of the
issuer of operator-issued device certificates start with "Huawei".
l If the base station cannot communicate with the U2020 after obtaining a device
certificate, the U2020 cannot record the information about the device certificate. In this
case, the U2020 cannot monitor the device certificate.
l During the period when base station software is rolled back to a version not supporting
offline certificate monitoring, the U2020 cannot update certificate status. After base
station software is upgraded to a version supporting offline certificate monitoring, the
U2020 can update certificate status.
The offline certificate monitoring function does not need to be activated. You can query and
export the basic information about abnormal certificates on the U2020. For details, see 4.4.3.4
Activation Verification and 4.4.4.4 Activation Verification.

SingleRAN
4.1.3.6 Certificate Usage in UMPT+UMPT Cold Backup Mode

In UMPT+UMPT cold backup mode, only one UMPT works at a time. The two UMPT
boards are deployed in the same logical slot and configured with the same logical slot number.
The data configuration for the certificate deployment location specifies the bound logical slot
number. For details of UMPT cold backup and logical slot numbers, see Base Station
Equipment Reliability.
During the deployment phase, apply for the operator-issued device certificate only for the
active UMPT.
During the operation phase, a CMPv2-based certificate application is triggered if all the
following conditions are met:
l The active UMPT becomes faulty.

l The active and standby UMPT boards are switched over.
l The standby UMPT applies for an operator-issued device certificate based on the
configuration file.
The two UMPT boards manage and use their own certificates.
In UMPT+UMPT cold backup mode, if both IPsec and PKI are deployed, the
IKEPEER.IDTYPE parameter can be set to IP or FQDN on the base station side. If this
parameter is set to FQDN, the SeGW should not check the ID of the base station.
4.1.3.7 Estimation of Certificate Reconfiguration Impact

This function estimates the impact of certificate reconfiguration on services based on the
existing IPsec and certificate configuration data. If a certificate reconfiguration may lead to a
site disconnection, the system displays a message indicating the high-risk issues or terminates
the operation to avoid configuration impact on services.
Estimation of certificate reconfiguration impact involves the following operations:
l Check whether the value of Local IP in the certificate request is the same as the value of
Local IP in the effective IKEPEER MO before running any of the following
commands:
– MOD CERTREQ
– ADD CA
– MOD CA
– MOD APPCERT
– MOD CERTMK
– MOD IKEPEER
– ADD IPSECBIND (old model)/ADD IPSECBINDITF (new model)
– ADD IPSECPOLICY
– MOD IPSECPOLICY
If the two Local IP values are different, certificate reconfiguration impact cannot be
estimated.
l Check whether the effective IKE/SSL certificate is using the local trust certificate to be
deleted (by running the RMV TRUSTCERT command).

SingleRAN
NOTE
This function cannot determine whether the peer trust certificate is deleted.
Estimation of certificate reconfiguration impact applies to the following configuration

scenarios: MML command configuration and CME XML batch configuration. Estimation of
trust certificate deletion applies only to MML command configuration scenarios.
l MML command configuration

Whether to estimate certificate reconfiguration impact is controlled by the Support
Forcible Execution parameter in the MML commands listed above.
– If this parameter is set to NO(No) in a command, certificate reconfiguration impact
is estimated after this command is delivered:
n If the estimation result is that services will be affected, a failure message is
returned and the failure cause is described.
n If the estimation result is that services will not be affected, certificate
reconfiguration is performed.
– If this parameter is set to YES(Yes) in a command, certificate reconfiguration is
performed without estimating the impact.
This function increases the execution time of a single MML command by up to 2s.
l CME XML batch configuration
The Precise Check option in the CME script export function determines whether to
estimate the impact of certificate reconfiguration on services. This option is selected by
default. When an operator exports a script, the CME estimates the impact on services. If
the commands in the script will affect services, the estimation results are displayed. If the
commands in the script will not affect services, the CME directly performs the certificate
reconfiguration.
This function does not apply to base stations using a WMPT, LMPT, GTMUb, or GTMUc as
the main control board.
4.1.3.8 Certificate Application of eCPRI Connections

Boards with eCPRI ports (BBP and AAU) are preconfigured with Huawei-issued device
certificates. If a PKI system is deployed on the operator's network, an AAU can apply for an
operator-issued device certificate and use the operator-issued device certificate to establish a
secure eCPRI connection with the BBU.
It is required that the AAU be added to the whitelist of the CA and the BBU be configured as
the RA to ensure that the AAU can successfully apply for an operator-issued device
certificate. During the certificate application and update, the BBU functions as the RA and
should have applied for an operator-issued device certificate. The private key file of the AAU
is not transferred out of the AAU.
The APPCERT.RRUCERTREQSW parameter specifies whether an AAU applies for an

operator-issued device certificate.
Currently, an AAU does not support manual application for an operator-issued device
certificate. It can only use CMPv2 to apply for an operator-issued device certificate from the
operator's CA through the BBU proxy.
Step 1 An AAU generates the certificate private key and certificate request file based on the
parameters in the CERTREQ MO.

SingleRAN
For an AAU, the certificate common name is always the ESN, the signature algorithm is
always SHA256, the key size is always 2048 bits, and the local name and local IP address do
not take effect.
Step 2 The AAU sends the certificate request file to the BBU.
Step 3 The BBU uses the certificate request file to apply for an operator-issued device certificate for
the AAU from the CA, and then delivers the certificate to the AAU.
----End
The BBU can control whether to allow AAUs to use Huawei certificates for connection. After
the certificates of all AAUs are replaced with the operator-issued device certificates, you can
run the SET RRUSECPOLICY command to disable authentication based on Huawei-issued
device certificates. In this case, the BBU accepts only the connection requests of AAUs using
operator-issued device certificates. In secure networking using certificate-based
authentication, if a new AAU is connected to the network, authentication based on Huawei-
issued device certificates must be enabled on the BBU. Otherwise, the AAU may fail to apply
for an operator-issued device certificate.
ALM-26565 RF Unit Certificate Fault is reported one hour after an AAU certificate
application or update fails or the AAU authentication mode is changed to anonymous
authentication.
Replacing the CA That Issues the AAU Certificate

The CA that issues the AAU certificate is the CA that issues the TLS certificate of the BBU.
If you need to replace the CA for the AAU, replace the CA by replacing the CA of the TLS
certificate of the BBU. The replacement of the CA takes effect only after the AAU is reset.
4.1.3.9 IPv6 Certificate

The base station supports IPv6 as the protocol version of the CA server/CRL server. In
addition, the IP address in SubjectAltName can be specified by the LOCALIP6 parameter in
the MOD CERTREQ or ADD CA command.
4.2 Network Analysis
4.2.1 Benefits
A PKI system manages digital certificates for network equipment. This helps operators
establish a trusted security domain and gain trust relationships with different vendors to
jointly establish a secure network environment.
4.2.2 Impacts
Network Impacts
A certificate application process prolongs base station deployment by approximately 10s.
A certificate application process prolongs base station controller deployment by

approximately 10s.

SingleRAN
Function Impacts
l GBFD-113526 BTS Supporting PKI
None
l WRFD-140210 NodeB PKI Support
None
l GBFD-160211 BSC Supporting PKI
Function Function Switch Reference
Name
Encrypted None SSL

Network
Management
l WRFD-160276 RNC Supporting PKI

Name
Security None Equipment Security

Management
l eCoordinator Supporting PKI

None
l LOFD-070212 eNodeB Supporting PKI Redundancy
None
l TDLOFD-070212 eNodeB Supporting PKI Redundancy
None
l MLOFD-070212 eNodeB Supporting PKI Redundancy
None
l FBFD-010023 Security Mechanism (gNodeB Supporting PKI Redundancy)
None
4.3 Requirements
4.3.1 Licenses
The licenses for the PKI feature have been activated for the base station and base station
controller. The eCoordinator/gNodeB does not require a license to support the PKI feature.
The following table lists the licenses controlling PKI.

SingleRAN
Feature Feature Name Model License NE Sales

ID Control Item Unit
Name
GBFD-113 BTS Supporting LGMIBTS BTS Supporting BSC6900 Per BTS

526 PKI PKI PKI (per BTS) BSC6910
WRFD-14 NodeB PKI LQW9PKI NodeB PKI NodeB Per NodeB

0210 Support 01 support(per
NodeB)
GBFD-160 BSC LGMIPKI BSC BSC6900 Per TRX

211 Supporting PKI Supporting PKI BSC6910
(per TRX)
WRFD-16 RNC LQW1PKI RNC BSC6900 Per Erl

0276 Supporting PKI E Supporting PKI BSC6910
(per Erl)
WRFD-16 RNC LQW1PKI RNC BSC6900 Per Mbps

0276 Supporting PKI M Supporting PKI BSC6910
(per Mbps)
NOTE
The rules for activating the license controlling PKI for a multimode base station are as follows:
l In co-transmission scenarios with a separate-MPT multimode base station, the license controlling
PKI needs to be activated for the mode that provides a transmission port. If another mode requires
certificate sharing, the license controlling PKI must also be activated for this mode.
l If a UTRPc board is used to connect to the transport network, the license controlling PKI must be
activated for the managing mode of the UTRPc board.
For a BSC6900 GU or BSC6910 GU, the license controlling PKI only needs to be activated for one
mode, that is, you can activate either the license for the BSC Supporting PKI feature or the license for
the RNC Supporting PKI feature.
4.3.2 Software
Before activating this function, ensure that its prerequisite functions have been activated and
mutually exclusive functions have been deactivated. For detailed operations, see the relevant
feature documents.
4.3.2.1 GBFD-113526 BTS Supporting PKI
Prerequisite Functions
Name
Abis over IP None IPv4 Transmission

SingleRAN
Mutually Exclusive Functions

None
4.3.2.2 WRFD-140210 NodeB PKI Support
Name
IP Transmission None IPv4 Transmission

Introduction on
Iub Interface

None
4.3.2.3 GBFD-160211 BSC Supporting PKI
None

None
4.3.2.4 WRFD-160276 RNC Supporting PKI
None

None
4.3.2.5 eCoordinator Supporting PKI
None

None

SingleRAN
4.3.2.6 LBFD-003010 Public Key Infrastructure (PKI)
None

None
4.3.2.7 MLBFD-12000312 Public Key Infrastructure (PKI)
None

None
4.3.2.8 TDLBFD-003010 Public Key Infrastructure (PKI)
None

Function Function Switch Reference (eRAN Feature
Name Documentation)
Virtual Routing None VRF (TDD)

and Forwarding
4.3.2.9 FBFD-010023 Security Mechanism (PKI)
None

None

SingleRAN
4.3.3 Hardware
Base Station Models

RAT Base Station Model
GSM 3900 and 5900 series base stations
UMTS l 3900 and 5900 series base stations

l DBS3900 LampSite and DBS5900 LampSite
l BTS3911E
LTE l 3900 and 5900 series base stations

l BTS3912E
l BTS3911E
NR l 3900 and 5900 series base stations. 3900 series base stations must be
configured with the BBU3910.
l DBS3900 LampSite and DBS5900 LampSite. DBS3900 LampSite
must be configured with the BBU3910.
Boards
The following table lists the hardware to be configured in base stations to support PKI.
Table 4-3 PKI hardware requirements
NE Hardware
GBTS GTMUb/GTMUc+UMPT_L/LMPT
eGBTS UMPT_G/UMDU_G/MDUC_G/GTMUb/GTMUc
NodeB UMPT_U/UTRPc/UMDU_U/MDUC_U
eNodeB UMPT_L/UMPT_T/LMPT/UTRPc/UMDU_L/UMDU_T
gNodeB UMPT_N
Multimode UMPT_G/UMDU_G/MDUC_G/UMPT_U/UMDU_U/MDUC_U/
base station UMPT_L/UMPT_T/UMDU_L/UMDU_T/LMPT/UTRPc
Base station l OMU

controller l SAU (the SAU obtains digital certificates from the OMU)
eCoordinator OMU
For details about the boards that support eCPRI, see the "Hardware" section in eCPRI.

SingleRAN
RF Modules
This function does not depend on RF modules.
4.3.4 Others
l A PKI server is deployed on the operator's network.
l Operator-issued device certificates and CRLs comply with IETF RFC 5280.
l The operator's CA supports CMPv2 defined in IETF RFC 4210, and the format of
certificate request messages complies with IETF RFC 4211.
l As stipulated in 3GPP TS 33.310, the Initialization Response message sent by the
operator's CA contains the operator's root certificate or certificate chain.
l The operator's CA is preconfigured with the Huawei root certificate.
4.4 Operation and Maintenance
4.4.1 When to Use

A Huawei-issued device certificate can meet the basic transmission security requirements, but
it does not support online update. Therefore, directly using a Huawei-issued device certificate
on the network has security risks. It is recommended that the operator deploy a PKI system on
the live network and use the operator-issued device certificate to replace the Huawei-issued
device certificate, so that the operator-issued device certificate can be updated online, which
minimizes security risks.
If the base stations and base station controllers on the live network need to interconnect with
the PKI system, enable the PKI feature for the base stations and base station controllers.
4.4.2 Precautions
Before deploying the PKI feature for a base station or base station controller, engineering
personnel must obtain CA information from CA maintenance personnel. The following table
lists the CA information that needs to be collected.
Items to Be Collected Required Parameter on the Base Station or

Base Station Controller Side
CA name CA.CANAME
RA name CA.RANAME
Uniform resource locator (URL) CA.URL

of the CA (Optional) CA.INITREQURL
Signature algorithm for CMP CA.SIGNALG

messages
Signature algorithm for the CA to CERTREQ.SIGNALG

issue certificates
Size of the certificate key CERTREQ.KEYSIZE

SingleRAN
Items to Be Collected Required Parameter on the Base Station or

Base Station Controller Side
Use of the certificate key CERTREQ.KEYUSAGE
Local name of the certificate CERTREQ.LOCALNAME
File name of the root certificate or TRUSTCERT.CERTNAME

certificate chain
(Optional) IP address of the CRL CRLTSK.IP

server
(Optional) user name for logging CRLTSK.USR

in to the CRL server
(Optional) password for logging in CRLTSK.PWD

to the CRL server
(Optional) CRL file name CRLTSK.FILENAME
(Optional) method of obtaining the CRLTSK.CRLGETMETHOD

CRL file
(Optional) name of the CRL server CRLTSK.SEARCHDN
(Optional) port number of the CRL CRLTSK.PORT

server
Before deploying the PKI feature for an eCoordinator, engineering personnel must obtain CA
information from CA maintenance personnel. The following table lists the CA information
that needs to be collected.
Items to Be Collected Required Parameter on the eCoordinator Side
Signature algorithm for the CA to SIGNALG

issue certificates
Size of the certificate key KEYSIZE
Use of the certificate key KEYUSAGE
Local name of the certificate LOCALNAME
File name of the trust certificate or CERTNAME

certificate chain
(Optional) IP address of the CRL IP

server
(Optional) user name for logging USR

in to the CRL server
(Optional) password for logging in PWD

to the CRL server

SingleRAN
Items to Be Collected Required Parameter on the eCoordinator Side
(Optional) CRL file name FILENAME
(Optional) method of obtaining the CRLGETMETHOD

CRL file
4.4.3 Deployment of PKI on the GBTS/eGBTS/NodeB/eNodeB/

gNodeB/Multimode Base Station
This section uses the networking illustrated in Figure 4-17 as an example to describe how to
deploy the PKI feature on the GBTS/eGBTS/NodeB/eNodeB/gNodeB/multimode base
station. A UMDU/MDUC can also be used in a co-MPT multimode base station in the secure
networking shown in Figure 4-17. However, a UMDU/MDUC cannot be used in a separate-
MPT multimode base station. The descriptions in this section are applicable to an eGBTS
using a GTMUc, UMPT, UMDU, or MDUC.
Figure 4-17 Example of the secure networking for the GBTS/eGBTS/NodeB/eNodeB/

gNodeB/multimode base station
4.4.3.1 Data Preparation

NOTE
In the following tables, "-" indicates that there is no special requirement for the parameter setting. You
can set the parameter based on site requirements.
Table 4-4 lists the data to be prepared for the deployment location of a certificate on the base
station (the CERTDEPLOY MO in MML configurations).

SingleRAN
Table 4-4 Data to be prepared for the deployment location of a certificate

Parameter Parameter ID Setting Notes
Name
Certification CERTDEPLOY.DEPL If a digital certificate is deployed on a main

Deploy Position OYTYPE control board, this parameter must be set to
Type DEFAULT. If a digital certificate is
deployed on another board in a specified
slot, this parameter must be set to
SPECIFIC. If no digital certificate is
deployed on the base station, this parameter
must be set to NULL.
Cabinet No. CERTDEPLOY.CN -
Subrack No. CERTDEPLOY.SRN
Slot No. CERTDEPLOY.SN
Table 4-5 lists the data to be prepared for a certificate request template of the base station (the
CERTREQ MO in MML configurations).
Table 4-5 Data to be prepared for a certificate request template

Name
Common Name CERTREQ.COMMNA The default value of the Common Name

ME field in a certificate request file is
XXX.huawei.com (XXX indicates the ESN of
the board connecting to the transport
network). Therefore, the recommended
value of this parameter is ESN. Currently,
this parameter cannot be set to MAC or IP.
Common Name CERTREQ.USERADDI -

Additional Info. NFO
Country CERTREQ.COUNTRY -
Organization CERTREQ.ORG -
Organizational CERTREQ.ORGUNIT -
Unit
State or CERTREQ.STATEPRO -
Province VINCENAME
Locality CERTREQ.LOCALITY -

SingleRAN

Name
Key Usage CERTREQ.KEYUSAG The recommended values are

E DIGITAL_SIGNATURE and
KEY_ENCIPHERMENT. If this
parameter is set to
DIGITAL_SIGNATURE, the key is used
to verify the peer's digital signature during a
CMPv2-based certificate application or
update, IKE negotiation, and SSL
authentication. If this parameter is set to
KEY_ENCIPHERMENT, the key is used
to encrypt transmission data during IKE
negotiation, IPsec negotiation, or SSL-based
key exchange.
Signature CERTREQ.SIGNALG l SHA256 is recommended.

Algorithm l MD5 is not recommended for use
because it provides low security. MD5
will be removed from signature
algorithms in later versions. The value
MD5(MD5) is supported in the current
version, but SHA256 takes effect in the
system instead of MD5. SHA1 will be
removed from signature algorithms in
later versions. SHA1 takes effect if this
parameter is set to SHA1(SHA1) in the
current version. The value SHA1(SHA1)
should be avoided. If the signature
algorithm is set to MD5 on a live
network but the peer equipment does not
support SHA256, certificate requests and
updates will fail after an upgrade to this
version. The signature algorithm must be
changed to SHA1 before certificate
requests or updates.
Key Size CERTREQ.KEYSIZE -
Local Name CERTREQ.LOCALNA If this parameter is not set, the default value
ME of the Common Name field in a certificate
is used. If this parameter is set, the value of
the Local Name field in a certificate must
be the same as the value of this parameter.
Local IP CERTREQ.LOCALIP If IDTYPE is set to IP(IP Identify), the

value of this parameter must be the same as
the value of LOCALIP in the IKEPEER
MO.

SingleRAN

Name
Local IPv6 CERTREQ.LOCALIP6 In IPv6 networking, if IDTYPE is set to

IP(IP Identify), the value of this parameter
must be the same as the value of
LOCALIP6 in the TUNNELITF MO.
The base station must be configured with CA information to apply for a certificate from the
CA. Table 4-6 lists the data to be prepared for the CA (the CA MO in MML configurations).
Table 4-6 Data to be prepared for the CA (1)

Name
Certificate CA.CANAME -
Authority Name
Certificate CA.URL Currently, base stations cannot translate

Authority URL domain names. Therefore, an IP address
instead of a domain name is used in the
URL.
The TCP port number is determined by the
CA. For example, the URL domain name of
the CA can be set to http://10.88.88.88:80/
pkix/.
For an IPv6 URL address, the format "[IP
address]:Port Number" must be used to
separate the IP address from the port
number, for example, https://
[2050::20:23:123]:34481/pkix/.
Signature CA.SIGNALG -
Algorithm
Certificate CA.RANAME Set this parameter if the customer's

Registration certificate registration server requires that
Name the value of the recipient field in the
received CMPv2-based certificate request
message be the name of the certificate
registration server.

SingleRAN

Name
Certificate CA.MODE l If this parameter is set to

Fetch Mode DEFAULT_MODE, the UPDSIP,
INITREQURL, and INITREQSIP
parameters do not need to be set. The
base station uses the O&M IP address
and URL as the source and destination
IP addresses, respectively, for routine
certificate management. Routine
certificate management involves
certificate application and certificate
update, both of which can be done
performed automatically or manually.
When applying for a certificate for the
first time during base station
deployment, the base station uses the
interface IP address or O&M IP address
as the source IP address, and the URL as
the destination IP address.
l If this parameter is set to
CFG_UPD_SIP, INITREQURL and
INITREQSIP do not need to be set. The
base station uses UPDSIP and URL as
the source and destination IP addresses,
respectively, for routine certificate
management. When applying for a
certificate for the first time during base
station deployment, the base station uses
the interface IP address or UPDS IP
address as the source IP address, and the
URL as the destination IP address. The
interface IP address is used during base
station deployment by PnP, and the
UPDS IP address is used during base
station deployment by USB.
l If this parameter is set to
CFG_INIT_UPD_ADDR:
– During daily certificate management,
the base station uses UPDSIP and
URL as the source and destination IP
addresses, respectively.
– When obtaining a certificate for the
first time during base station
deployment, the base station uses the
interface IP address (PnP base station
deployment) or INITREQSIP (base
station deployment using a USB flash
drive) as the source IP address, and

SingleRAN

Name
uses INITREQURL as the

destination IP address.
Certificate CA.UPDSIP -
Update Source
IP
CA URL CA.INITREQURL -
During Site
Deployment
Source IP for CA.INITREQSIP -

Applying for a
Certificate
During Site
Deployment
Slave CA.SLVURL -
Certificate
Authority URL
Slave CA URL CA.SLVINITREQURL -

During Site
Deployment
Certificate CA.CERTREQSW -
Request Switch
Local Name CA.LOCALNAME -
Local IP CA.LOCALIP -
Support CA.FORCEEXECUTE For setting suggestions, see 4.1.3.7

Forcible Estimation of Certificate Reconfiguration
Execution Impact.
NOTE
If O&M data flows are transmitted by the IPsec tunnel, the O&M IP address cannot be used for data that
is not protected by IPsec. If O&M data flows are not transmitted by the IPsec tunnel, the O&M IP
address cannot be used for data that is protected by IPsec.
Table 4-7 lists the data to be prepared for a device certificate (the CERTMK MO in MML
configurations).

SingleRAN
Table 4-7 Data to be prepared for a device certificate

Name
Certificate File CERTMK.APPCERT l If an operator-issued device certificate is

Name used for identity authentication between
the base station and SeGW, two
CERTMK MOs must be configured to
specify an operator-issued device
certificate and a Huawei-issued device
certificate. For Huawei-issued device
certificates, this parameter is set to
appcert.pem. For operator-issued device
certificates, this parameter is set to
OPKIDevCert.cer during base station
deployment by PnP.
l If a Huawei-issued device certificate is
used for identity authentication between
the base station and SeGW, only one
CERTMK MO needs to be configured
to specify a Huawei-issued device
certificate. This parameter is set to
appcert.pem accordingly. Users cannot
modify or remove this MO.
Table 4-8 lists the data to be prepared for an active certificate (the APPCERT MO in MML
configurations). Active certificates are device certificates that are currently used by a base
station.
Table 4-8 Data to be prepared for an active certificate

Name
Application APPCERT.APPTYPE This parameter must be set to IKE for IKE

Type authentication. (The base station controllers
do not support IKE authentication.)
This parameter must be set to SSL for SSL
authentication.
Certificate File APPCERT.APPCERT Base stations do not have special

Name requirements for the setting of this
parameter.
Table 4-9 lists the data to be prepared for a trust certificate (the TRUSTCERT MO in MML
configurations).

SingleRAN
Table 4-9 Data to be prepared for a trust certificate

Name
Certificate File TRUSTCERT.CERTN The base station must be configured with an

Name AME operator's trust certificate and a Huawei
trust certificate. For the Huawei trust
certificate, this parameter is set to
caroot.pem on the base station side and is
set to rootca.pem on the base station
controller side. For the operator's trust
certificate, this parameter is set to CN.cer
when automatic certificate application is
used. The value of CN must be the same as
that in the Subject field of the trust
certificate.
If the operator's CA system has a multi-
layer structure, all trust certificates in the
certificate chain must be configured. If the
certificates of different levels of CAs in the
certificate chain are stored separately, run
the ADD TRUSTCERT command for each
certificate you want to add.
Table 4-10 lists the data to be prepared for a periodic certificate validity check task (the
CERTCHKTSK MO in MML configurations).
Table 4-10 Data to be prepared for a periodic certificate validity check task

Name
Checking CERTCHKTSK.PERI The default value is recommended.

Period OD
Alarm CERTCHKTSK.ALMR The default value is recommended.

Threshold NG
Update Method CERTCHKTSK.UPDA The recommended value of this parameter is

TEMETHOD CMP.
Automatic CERTCHKTSK.AUTO It is recommended that this parameter be set

Certificate REAPPLYSW to ON.
Reapplication
Switch
(Optional) Prepare CRL data if the base station needs to obtain CRL information from the
CA. Table 4-11 lists the data to be prepared for a CRL (the CRL MO in MML
configurations).

SingleRAN
Table 4-11 Data to be prepared for a CRL

Name
CRL File Name CRL.CERTNAME -
(Optional) Prepare data related to CRL usage policies. Table 4-12 lists the data to be prepared
for these policies (the CRLPOLICY MO in MML configurations).
Table 4-12 Data to be prepared for CRL usage policies

Name
CRL Using CRLPOLICY.CRLPOL Operators can set this parameter based on

Policy ICY site requirements. During base station
deployment by PnP, the base station does
not support CRL-based certificate validity
checks.
(Optional) Prepare data related to a periodic CRL download task. Table 4-13 lists the data to
be prepared for the task (the CRLTSK MO in MML configurations).
Table 4-13 Data to be prepared for a periodic CRL download task

Name
IP Address CRLTSK.IP Set this parameter to the IP address of the

CRL server.
User Name CRLTSK.USR -
Password CRLTSK.PWD -
File Name CRLTSK.FILENAME -
Using CRL's CRLTSK.ISCRLTIME If this parameter is set to ENABLE, the

Next Update base station downloads a CRL when the
next update time arrives.
CRL Updating CRLTSK.PERIOD This parameter must be set when

Period ISCRLTIME is set to DISABLE.
Access Method CRLTSK.CRLGETME The recommended value of this parameter is

THOD LDAP. Set this parameter to FTP only
when the peer device does not support
LDAP.

SingleRAN

Name
Distinguish CRLTSK.SEARCHDN This parameter must be set when

Name CRLGETMETHOD is set to LDAP.
Port No. CRLTSK.PORT This parameter must be set when

CRLGETMETHOD is set to LDAP.
Task ID CRLTSK.TSKID -
Source IP CRLTSK.SIP If this parameter is not set, the base station

uses the O&M IP address as the source IP
address to update a CRL.
Connection CRLTSK.CONNMODE This parameter takes effect only when the

Mode CRLGETMETHOD parameter is set to
LDAP.
Authenticate CRLTSK.AUTHPEER This parameter takes effect only when the

Peer CRLGETMETHOD parameter is set to
LDAP.
If this parameter is set to
ENABLE(Enable), ensure that the NEs and
the CRL server have been configured with
the CA trust certificates and device
certificates.
(Optional) Prepare data to manually download an operator's root certificate or CRL from an
FTP server. Table 4-14 lists the data to be prepared for downloading a certificate file (the
DLD CERTFILE in MML configurations).
Table 4-14 Data to be prepared for downloading a certificate file

Name
FTP Server IP IP -
User Name USR -
Password PWD -
Source File SRCF -

Name
Destination File DSTF It is recommended that this parameter be set

Name to the same value as SRCF.
Guage Option GA This parameter determines whether to report

the progress of file downloading. The
recommended value of this parameter is Y.
Certificate Type CT -

SingleRAN
(Optional) Prepare data to manually trigger a CMPv2-based certificate application. Table

4-15 lists the data to be prepared for applying for a device certificate based on CMPv2. The
corresponding MML command is REQ DEVCERT.
Table 4-15 Data to be prepared for applying for a device certificate based on CMPv2
Name
Authority Name
Certificate File CERTMK.APPCERT -

Name
Renew Key REKEY The recommended value of this parameter is

Yes.
(Optional) Prepare data to manually trigger a CMPv2-based certificate update. Table 4-16
lists the data to be prepared for updating a device certificate (the UPD DEVCERT in MML
configurations) based on CMPv2.
Table 4-16 Data to be prepared for updating a device certificate based on CMPv2
Name
Certificate File CERTMK.APPCERT This parameter specifies a certificate to be

Name updated.

Yes.
4.4.3.2 Using MML Commands
Activation Command Examples

The following is an MML command example of how to activate an operator-issued device
certificate.
//Setting the deployment position of a certificate (the base station needs to be
reset for the modification to take effect)
SET CERTDEPLOY: DEPLOYTYPE=DEFAULT;
//Modifying configurations of a certificate request template
MOD CERTREQ: COMMNAME=ESN, USERADDINFO=".huawei.com", COUNTRY="cn", ORG="ITEF",
ORGUNIT="Hw", STATEPROVINCENAME="sc", LOCALITY="cd",
KEYUSAGE=DATA_ENCIPHERMENT-1&DIGITAL_SIGNATURE-1&KEY_AGREEMENT-1&KEY_ENCIPHERMENT-
1, SIGNALG=SHA256, KEYSIZE=KEYSIZE2048, LOCALNAME="abcdefghijklmn.huawei.com",
LOCALIP="10.20.20.188";

SingleRAN
//Adding an operator's CA
//If the base station can access the CA either through an external network or
through the intranet and O&M data is protected by IPsec, you are advised to set
the source IP addresses for certificate application and update to an interface IP
address and an O&M IP address (for example, 10.31.31.188), respectively. The
following is an example:
ADD CA: CANAME="C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca1",
URL="http://10.88.88.88:80/pkix/", SIGNALG=SHA256, MODE= CFG_INIT_UPD_ADDR,
UPDSIP="10.31.31.188",INITREQURL="http://10.89.89.89:80/
pkix/",INITREQSIP="10.20.20.188";
through the intranet, and O&M data is not protected by IPsec, you are advised to
set the source IP addresses for certificate application and update to an
interface IP address and an intranet IP address(for example, 10.45.45.45),
respectively.
//If the base station can access the CA only through an external network, you are
advised to set the source IP addresses for both certificate application and
update to interface IP addresses. The following is an example:
//Downloading an operator's root certificate from an FTP server (assume that the
FTP server is deployed on the U2020, indicating that the IP address of the FTP
server is the same as that of the U2020)
DLD
CERTFILE:IP="10.60.60.60",USR="admin",PWD="*****",SRCF="OperationCA.cer",DSTF="Ope
rationCA.cer";
//Adding an operator's root certificate as the trust certificate
ADD TRUSTCERT: CERTNAME="OperationCA.cer";
//Setting information required for the base station to apply for an operator-
issued device certificate based on CMPv2 when the certificate application needs
to be manually triggered
//(Skip this step when the certificate application is automatically triggered.)
REQ DEVCERT: CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd, CN=eca1",
APPCERT="OPKIDevCert.cer";
//Modifying configurations of an active certificate
MOD APPCERT: APPTYPE=IKE, APPCERT="OPKIDevCert.cer";
NOTE
After the active IKE certificate is changed by running the MOD APPCERT command, if IKE
authentication uses the new certificate and the current IKE SA is normal, the base station automatically
initiates an IKE renegotiation.
//Setting a periodic certificate validity check task
SET CERTCHKTSK: PERIOD=7, ALMRNG=30, UPDATEMETHOD=CMP;
//(Optional) Downloading the CRL file from the FTP server (If the FTP server is
deployed on the U2020, the IP address of the FTP server is the same as that of
the U2020.)
DLD
CERTFILE:IP="10.60.60.60",USR="admin",PWD="*****",SRCF="eNodeB.crl",DSTF="eNodeB.c
rl";
//(Optional, required only when a manual certificate application procedure is
used) Loading a CRL file
ADD CRL: CERTNAME="eNodeB.crl";
//(Optional) Setting a CRL usage policy
SET CRLPOLICY:CRLPOLICY= NOVERIFY;
//(Optional) Adding a task of periodically downloading the CRL
ADD CRLTSK: IP="10.86.86.86", USR="admin", PWD="*****", FILENAME="eNodeB.crl",
ISCRLTIME=DISABLE, PERIOD=24, TSKID=0, CRLGETMETHOD=FTP;
In addition to the preceding steps, perform the following step to manually trigger a certificate
update. When you run the UPD DEVCERT command to update a certificate, the certificate
update will fail if the base station is performing an IKE or SSL negotiation. You need to run
this command after the negotiation is completed.

SingleRAN
UPD DEVCERT: APPCERT="OPKIDevCert.cer",REKEY=YES;
Certificate sharing configuration:

//Setting the deployment location of a certificate
SET CERTDEPLOY: DEPLOYTYPE=SPECIFIC, CN=0, SRN=0, SN=6;
Deactivation Command Examples

Step 1 Run the RMV CA command to remove the CA.
Step 2 (Optional) Run the RMV CRLTSK command to remove the task of automatically updating
CRL whose CRLGETMETHOD is set to LDAP.
----End
4.4.3.3 Using the CME

You can use either of the following methods to deploy the PKI feature for newly deployed
base stations: CME Summary batch configuration and CME transport security wizard
configuration.
CME Summary Batch Configuration

This feature can be activated using the CME. This section uses the eNodeB as an example.
For detailed operations, see CME-based Feature Configuration or the CME online help (click
in an active CME window).
Configuration CME Online Help

Type
Single configuration CME Management > CME Guidelines > Getting Started with
the CME > Introduction to Data Configuration Operations
Batch eGBTS CME Management > CME Guidelines > GSM Application
configuration Management > Base Station Related Operations > Importing
and Exporting eGBTS Data for Batch Reconfiguration
Batch NodeB CME Management > CME Guidelines > UMTS Application
configuration Management > NodeB Related Operations > Importing and
Exporting NodeB Data for Batch Configuration
Batch eNodeB CME Management > CME Guidelines > LTE Application
configuration Management > eNodeB Related Operations > Importing and
Exporting eNodeB Data for Batch Configuration
Batch gNodeB CME Management > CME Guidelines > NR Application

configuration Management > gNodeB Related Operations > Importing and
Exporting gNodeB Data for Batch Configuration
CME Transport Security Wizard Configuration

You can use the transport security wizard to configure the parameters for the PKI and IPsec
features on the CME. The wizard will guide you to configure most of the key parameters for

SingleRAN
PKI and IPsec networking. After the wizard configuration is completed, the CME
automatically imports the configured parameters to the Summary data file and prompts which
parameters must be manually configured in the Summary data file (for example, the UPDSIP
parameter in the CA MO).
Figure 4-18 shows the procedure for configuring data using the CME transport security
wizard.

SingleRAN
Figure 4-18 Procedure for configuring data using the CME transport security wizard
Figure 4-19 shows the PKI attribute selection in the CME transport security wizard.

SingleRAN
Figure 4-19 PKI attribute selection
For details on how to configure the PKI parameters in the CME transport security wizard, see
4.4.3.1 Data Preparation. For details on how to configure IPsec parameters, see the "Using
the CME" section in IPsec.

SingleRAN
After configurations on the CME transport security wizard are complete, the IPsec and PKI
parameter setting tables are exported, displaying the IPsec and KPI parameters that have been
configured and the parameters that need to be manually configured in the summary data file.
You can adjust the configured parameters in the summary data file based on actual conditions.
For the configuration path and interface for the transport security wizard, see "Customizing a
Summary Data File Using the Transmission Security Wizard" in the "Customizing a Summary
Data File" section of CME Product Documentation.
The CME transport security wizard has the following restrictions for configuring PKI:
l PKI redundancy cannot be configured.

l SSL transmission cannot be configured for obtaining the CRL.
l Base Station Supporting Multi-operator PKI cannot be configured.
l PKI parameters can be configured for the GBTS only when it is configured with
GTMUb/GTMUc+UMPT_L/LMPT. PKI parameters for the eGBTS, NodeB, eNodeB,
and gNodeB can be configured.
4.4.3.4 Activation Verification
Observing the PKI Feature

Step 1 Run the MML command DSP APPCERT to check the status of device certificates.
If the values of Certificate File Name, Issuer, and Common Name are correct and the value
of Status is Normal in the query result, the device certificate has been loaded to the base
station.
Step 2 Run the MML command DSP TRUSTCERT to check the status of trust certificates.
If the value of Status is Normal in the query result, the trust certificate has been loaded to the
base station.
Step 3 (Optional) Run the MML command DSP CRL to check the CRL status.
If the value of Status is Normal in the query result, the CRL has been loaded to the base
station.
----End
Observing Certificate Sharing

Step 1 Run the MML command DSP CERTSYNCINFO to check the status of certificate sharing.
If the value of Status is Normal in the query result, certificate sharing is successful.
----End
Observing Offline Certificate Monitoring

Step 1 On the U2020, choose Security > Certificate Authentication Management > Offline
Certificate Management. All device certificates in abnormal states are displayed on the
U2020.

SingleRAN
Step 2 (Optional) To export information of device certificates in abnormal states, click Export. If the
On disconnected NE or On deleted NE check box is selected, you also need to set the
duration in which the device certificates remain in the state.
----End
4.4.4 Deployment of PKI on the eGBTS using a GTMUb

deploy the PKI feature on the eGBTS using a GTMUb. This networking scenario supports
only SSL authentication.
Figure 4-20 Example of the secure networking for the eGBTS using a GTMUb

NOTE
Table 4-17 lists the data to be prepared for applying for a certificate from the CA (the SSL
MO in MML configurations).

SingleRAN
Table 4-17 Data to be prepared for applying for a certificate from the CA
Name
Common Name This parameter is The value of the Common Name field in a
manually set on the CA certificate request file consists of Common
and it does not have a Name+Common Name Additional Info.
parameter ID. The recommended value of the Common
Name field is XXX.huawei.com (XXX
indicates the ESN of the board connecting
to the transport network).
Common Name This parameter is The recommended value of this parameter

Additional Info. manually set on the CA is .huawei.com.
and it does not have a
parameter ID.
Country This parameter is -

manually set on the CA
parameter ID.
Organization This parameter is -

parameter ID.
Organizational This parameter is -

Unit manually set on the CA
parameter ID.
State or This parameter is -

Province manually set on the CA
parameter ID.
Locality This parameter is -

parameter ID.
Key Usage This parameter is The recommended values are

manually set on the CA DIGITAL_SIGNATURE and
and it does not have a KEY_ENCIPHERMENT. If this parameter
parameter ID. is set to DIGITAL_SIGNATURE, the key
is used to verify the peer's digital signature
during a CMPv2-based certificate
application or update, IKE negotiation, and
SSL authentication. If this parameter is set
to KEY_ENCIPHERMENT, the key is
used to encrypt transmission data during
IKE negotiation, IPsec negotiation, or SSL-
based key exchange.

SingleRAN

Name
Signature This parameter is Secure hash algorithm 256 (SHA256) is

Algorithm manually set on the CA recommended for signing a certificate
and it does not have a request file.
parameter ID. MD5 is not recommended for use because it
provides low security. MD5 will be
removed from signature algorithms in later
versions. The value MD5(MD5) is
supported in the current version, but
SHA256 takes effect in the system instead
of MD5. SHA1 will be removed from
signature algorithms in later versions. SHA1
takes effect if this parameter is set to
SHA1(SHA1) in the current version. The
value SHA1(SHA1) should be avoided. If
the signature algorithm is set to MD5 on a
live network but the peer equipment does
not support SHA256, certificate requests
and updates will fail after an upgrade to this
version or a later version. The signature
algorithm must be changed to SHA1 before
certificate requests or updates.
Key Size This parameter is -

parameter ID.
Local Name This parameter is l If this parameter is not set, the default
manually set on the CA value of the Common Name field in a
and it does not have a certificate is used.
parameter ID. l If this parameter is set, the value of the
Local Name field in a certificate must be
the same as the value of this parameter.
Root Certificate SSL.ROOTCERT -

File Name
Certificate File SSL.PUBCERT -

Name
Private Key SSL.PRIVKEY -

File Name
Private Key SSL.PKPENABLESTA It is recommended that the private key

Password password protection be enabled for security
Enabled State reasons.
Private Key SSL.PWD -

Password

SingleRAN

Name
Certificate SSL.CRLENABLESTA -
Revocation List
File Enabled
State
Certificate SSL.CRL -
Revocation List
File Name
Certificate SSL.CCAENABLESTA If the local certificate chain is different from

Chain File the peer certificate chain, set this parameter
Enabled State to ENABLE, and set the CERTCHAIN
parameter to the certificate chain file name.
Certificate SSL.CERTCHAIN -
Chain File
Name

Name
Certification CERTDEPLOY.DEPL Set this parameter to NULL for the eGBTS

Deploy Position OYTYPE using a GTMUb.
Type
Table 4-19 lists the data to be prepared for downloading an operator's root certificate, public
key, private key, or CRL file from an FTP server. The corresponding MML command is DLD
GENFILE.

Name
Source File SRCF -

Name

SingleRAN

Name
Type TYPE Set this parameter to the SSL type.

IP Mode MODE This parameter indicates the IP mode of the

FTP server.
FTP Server IP IP -
User Name USR -
Password PWD -


certificate.
NOTE
If multi-level CAs are deployed in the operator's PKI system and the local certificate chain is different
from the peer certificate chain, you also need to run the SET CERTFILE command to configure the
peer certificate chain.
//There are no MML commands for steps 1 and 2.
//Upload the operator's root certificate and CRL file to the FTP server.
//Based on the data plan, apply for a device certificate from the CA, and upload
the public key certificate (device certificate) and private key file generated by
the CA to the FTP server.
//Downloading the operator's root certificate, public key certificate, private
key file, and CRL file from the FTP server (assume that the FTP server is on the
U2020 and the FTP server and U2020 have the same IP address)
//Setting the certification deployment position so that the certificate is not
deployed on the base station
SET CERTDEPLOY:DEPLOYTYPE=NULL;
//Downloading the operator's root certificate from the FTP server
DLD
GENFILE:SRCF="OperationCA.cer",TYPE=SSL,DSTF="OperationCA.cer",MODE=IPV4,IP="10.60
.60.60",USR="admin",PWD="*****";
//Downloading the public key certificate from the FTP server
DLD
GENFILE:SRCF="OperationDev.cer",TYPE=SSL,DSTF="OperationDev.cer",MODE=IPV4,IP="10.
60.60.60",USR="admin",PWD="*****";
//Downloading the private key file from the FTP server
DLD
GENFILE:SRCF="OperationDevPri.cer",TYPE=SSL,DSTF="OperationDevPri.cer",MODE=IPV4,I
P="10.60.60.60",USR="admin",PWD="*****";
//Downloading the CRL file from the FTP server
DLD
GENFILE:SRCF="eGBTS.crl",TYPE=SSL,DSTF="eGBTS.crl",MODE=IPV4,IP="10.60.60.60",USR=
"admin",PWD="*****";
//Setting the operator's root certificate, public key certificate, private key
file, and CRL file
SET CERTFILE:ROOTCERT="OperationCA.cer ",PUBCERT="OperationDev.cer ",PRIVKEY="

SingleRAN
OperationDevPri.cer",PKPENABLESTA=DISABLE,CRLENABLESTA=ENABLE,CRL="eNodeB.crl
",CCAENABLESTA=DISABLE;

For detailed operations, see CME-based Feature Configuration.

Step 1 Run the SET SSLAUTHMODE command to set Authentication Mode to PEER(Verify
Peer Certificate).
Step 2 On the U2020, choose Security > Certificate Authentication Management > SSL
Connection Management to open the SSL Connection Management window. Then,
observe Connection Status of the base station.
If the value of Connection Status is Connected, an SSL connection has been successfully
established.
If the SSL connection setup fails, go to the next step.
Step 3 Run the SET CONNTYPE command to set Connection Type to SSL(Only SSL
Connection).
Step 4 In the SSL Connection Management window, select the base station, and then observe the
SSL connection status.
Then, observe Connection Status of the base station. If the value of Connection Status is
Connected, an SSL connection has been successfully established.
----End

The procedure for observing offline certificate monitoring of an eGBTS configured with a
GTMUb is the same as that of an eGBTS configured with a UMPT, UMDU, or MDUC. For
details, see Observing Offline Certificate Monitoring in 4.4.3 Deployment of PKI on the
GBTS/eGBTS/NodeB/eNodeB/gNodeB/Multimode Base Station.
4.4.5 Deployment of PKI on a NodeB Using a WMPT

deploy the PKI feature on the NodeB that uses a WMPT as the main control board and is not
configured with a UTRPc. This networking scenario supports only SSL authentication.

SingleRAN
Figure 4-21 Example of the secure networking for the NodeB that uses a WMPT as the main
control board and is not configured with a UTRPc

NOTE
Table 4-20 lists the data to be prepared for applying for a certificate from the CA (the SSL
MO in MML configurations).
Table 4-20 Data to be prepared for applying for a certificate from the CA
Name
Common Name This parameter is The value of the Common Name field in a
manually set on the CA certificate request file consists of Common
and it does not have a Name+Common Name Additional Info.
parameter ID. The recommended value of the Common
Name field is XXX.huawei.com (XXX
indicates the ESN of the board connecting to
the transport network).
Common Name This parameter is The recommended value of this parameter

Additional Info. manually set on the CA is .huawei.com.
parameter ID.

SingleRAN

Name
Country This parameter is -

parameter ID.
Organization This parameter is -

parameter ID.
Organizational This parameter is -

Unit manually set on the CA
parameter ID.
State or Province This parameter is -

parameter ID.
Locality This parameter is -

parameter ID.
Key Usage This parameter is The recommended values are

manually set on the CA DIGITAL_SIGNATURE and
and it does not have a KEY_ENCIPHERMENT. If this parameter
parameter ID. is set to DIGITAL_SIGNATURE, the key
is used to verify the peer's digital signature
during a CMPv2-based certificate
application or update, IKE negotiation, and
SSL authentication. If this parameter is set
to KEY_ENCIPHERMENT, the key is
used to encrypt transmission data during
IKE negotiation, IPsec negotiation, or SSL-
based key exchange.

SingleRAN

Name
Signature This parameter is Secure hash algorithm 256 (SHA256) is

Algorithm manually set on the CA recommended for signing a certificate
and it does not have a request file.
parameter ID. MD5 is not recommended for use because it
provides low security. MD5 will be removed
from signature algorithms in later versions.
The value MD5(MD5) is supported in the
current version, but SHA256 takes effect in
the system instead of MD5. SHA1 will be
versions. SHA1 takes effect if this parameter
is set to SHA1(SHA1) in the current
version. The value SHA1(SHA1) should be
avoided. If the signature algorithm is set to
MD5 on a live network but the peer
equipment does not support SHA256,
certificate requests and updates will fail
after an upgrade to this version or a later
changed to SHA1 before certificate requests
or updates.
Key Size This parameter is -

parameter ID.
Local Name This parameter is l If this parameter is not set, the default
manually set on the CA value of the Common Name field in a
and it does not have a certificate is used.
parameter ID. l If this parameter is set, the value of the
Local Name field in a certificate must be
Root Certificate SSL.ROOTCERT -

File Name
Certificate File SSL.PUBCERT -

Name
Private Key File SSL.PRIVKEY -

Name
Private Key SSL.PKPENABLEST It is recommended that the private key

Password A password protection be enabled for security
Enabled State reasons.
Private Key SSL.PWD -

Password

SingleRAN

Name
Certificate SSL.CRLENABLEST -
Revocation List A
File Enabled
State
Certificate SSL.CRL -
Revocation List
File Name
Certificate Chain SSL.CCAENABLEST If the local certificate chain is different from

File Enabled A the peer certificate chain, set this parameter
State to ENABLE, and set the CERTCHAIN
parameter to the certificate chain file name.
Certificate Chain SSL.CERTCHAIN -

File Name

Name
Certification CERTDEPLOY.DEPL Set this parameter to NULL for the NodeB

Deploy Position OYTYPE that uses a UMPT as the main control board
Type and is not configured with a UTPRc.
Table 4-22 lists the data to be prepared for downloading an operator's root certificate, public
key, private key, or CRL file from an FTP server. The corresponding MML command is DLD
GENFILE.

Name
Source File SRCF -

Name
Type TYPE Set this parameter to the SSL type.

SingleRAN

Name

IP Mode MODE This parameter indicates the IP mode of the

FTP server.
FTP Server IP IP -
User Name USR -
Password PWD -


certificate.
NOTE
If multi-level CAs are deployed in the operator's PKI system and the local certificate chain is different
from the peer certificate chain, you also need to run the SET CERTFILE command to configure the
peer certificate chain.
//There are no MML commands for steps 1 and 2.
//Upload the operator's root certificate and CRL file to the FTP server.
//Based on the data plan, apply for a device certificate from the CA, and upload
the public key certificate (device certificate) and private key file generated by
the CA to the FTP server.
//Downloading the operator's root certificate, public key certificate, private
key file, and CRL file from the FTP server (assume that the FTP server is on the
U2020 and the FTP server and U2020 have the same IP address)
//Setting the certification deployment position so that the certificate is not
deployed on the base station
SET CERTDEPLOY:DEPLOYTYPE=NULL;
//Downloading the operator's root certificate from the FTP server
DLD
GENFILE:SRCF="OperationCA.cer",TYPE=SSL,DSTF="OperationCA.cer",MODE=IPV4,IP="10.60
.60.60",USR="admin",PWD="*****";
//Downloading the public key certificate from the FTP server
DLD
GENFILE:SRCF="OperationDev.cer",TYPE=SSL,DSTF="OperationDev.cer",MODE=IPV4,IP="10.
60.60.60",USR="admin",PWD="*****";
//Downloading the private key file from the FTP server
DLD
GENFILE:SRCF="OperationDevPri.cer",TYPE=SSL,DSTF="OperationDevPri.cer",MODE=IPV4,I
P="10.60.60.60",USR="admin",PWD="*****";
//Downloading the CRL file from the FTP server
DLD
GENFILE:SRCF="NodeB.crl",TYPE=SSL,DSTF="NodeB.crl",MODE=IPV4,IP="10.60.60.60",USR=
"admin",PWD="*****";
//Setting the operator's root certificate, public key certificate, private key
file, and CRL file
SET CERTFILE:ROOTCERT="OperationCA.cer ",PUBCERT="OperationDev.cer ",PRIVKEY="
OperationDevPri.cer",PKPENABLESTA=DISABLE,CRLENABLESTA=ENABLE,CRL="NodeB.crl
",CCAENABLESTA=DISABLE;

SingleRAN


Step 1 Run the SET SSLAUTHMODE command to set Authentication Mode to PEER(Verify
Peer Certificate).
Step 2 On the U2020, choose Security > Certificate Authentication Management > SSL
Connection Management to open the SSL Connection Management window. Then,
observe Connection Status of the base station.
If the value of this field is Connected, an SSL connection has been successfully established.
If the SSL connection setup fails, go to the next step.
Step 3 Run the SET CONNTYPE command to set Connection Type to SSL(Only SSL
Connection).
Step 4 In the SSL Connection Management window, select the base station, and then observe the
SSL connection status.
If the value of Connection Status is Connected, an SSL connection has been successfully
established.
----End

The procedure for observing offline certificate monitoring of a NodeB configured with a
WMPT is the same as that of a NodeB configured with a UMPT, UMDU, MDUC, or UTRPc.
For details, see Observing Offline Certificate Monitoring in 4.4.3 Deployment of PKI on
the GBTS/eGBTS/NodeB/eNodeB/gNodeB/Multimode Base Station.
4.4.6 Deployment of PKI on the Base Station Controller

This section describes how to deploy the PKI feature by using MML commands. For details
about how to deploy the PKI feature by using the U2020 client, see the U2020 Help.
deploy the PKI feature on the base station controller.

SingleRAN
Figure 4-22 Example of the secure networking for the base station controller

NOTE
Table 4-23 lists the data to be prepared for a certificate request template (the CERTREQ MO
in MML configurations).

Name
Common Name CERTREQ.COMMNA The default value of the Common Name

ME field in a certificate request file is
XXX.huawei.com (XXX indicates the ESN of
the board connecting to the transport
network). Therefore, the recommended
value of this parameter is ESN. Currently,
this parameter cannot be set to MAC or IP.
Common Name CERTREQ.USERADDI -

Additional NFO
Information
Country CERTREQ.COUNTRY -
Organization CERTREQ.ORG -
Organizational CERTREQ.ORGUNIT -
Unit

SingleRAN

Name
State or CERTREQ.STATEPRO -
Province VINCENAME
Locality CERTREQ.LOCALITY -
Key Usage CERTREQ.KEYUSAG The recommended values are

E DIGITAL_SIGNATURE and
KEY_ENCIPHERMENT. If this
parameter is set to
DIGITAL_SIGNATURE, the key is used
to verify the peer's digital signature during
SSL authentication and CMPv2-based
certificate application or update. If this
parameter is set to
KEY_ENCIPHERMENT, the key is used
to encrypt the key for data transmission
during SSL-based key exchange.
Signature CERTREQ.SIGNALG SHA256 is recommended.

Algorithm MD5 is not recommended for use because it
of MD5. If the signature algorithm is set to
or updates.
Local Name CERTREQ.LOCALNA If this parameter is not set, the default value
ME of the Common Name field in a certificate
is used. If this parameter is set, the value of
the Local Name field in a certificate must be
Local IP CERTREQ.LOCALIP The recommended value of this parameter is

the external virtual IP address of the OMU.
The base station controller must be configured with CA information to apply for a certificate
from the CA. Table 4-24 lists the data to be prepared for the CA (the CA MO).

SingleRAN
Table 4-24 Data to be prepared for the CA

Name
Certificate CA.CANAME This parameter indicates the name of the

Authority Name CA on the operator's PKI server.
During a CMPv2-based certificate
procedure, the value of the Recipient field
in a CMPv2 message sent to the CMP
server equals the value of this parameter.
For details about how to configure this
parameter, see Figure 4-23.
For example, if the Subject name of the
certificate used for signing CMP messages
on the CA/RA is C = AU, S = Some-State,
L = cd, O = Internet Widgits Pty Ltd, OU
= Wireless, CN = eca1, E =
rosa@huawei.com, CANAME for the
organization must be set to C = AU, S =
Some-State, L = cd, O = Internet Widgits
Pty Ltd, OU = Wireless, CN = eca1, E =
rosa@huawei.com. To prevent errors
during the execution of the REQ
DEVCERT command, all of the following
conditions must be met: The character type
for the C, S, L, O, OU, and CN fields is
PRINTABLE. The character type for the E
field is IA5. The S field can be replaced
with the ST field. For base station
controllers, the S and ST fields are regarded
as the same field.
For details about the character set of the
PRINTABLE type, see RFC 3642.
Certificate CA.URL Currently, the base station controller cannot

Authority URL translate domain names. Therefore, an IP
address instead of a domain name is used in
the URL.
By default, the CA uses TCP port 80 for
HTTP services and TCP port 443 for
HTTPS services. The TCP port number is
determined by the CA. For example, the
URL domain name of the CA can be set to
http://10.88.88.88:80/pkix/.
Signature CA.SIGNALG -
Algorithm

SingleRAN

Name
Certificate CA.MODE If this parameter is set to

Fetch Mode DEFAULT_MODE, the UPDSIP
parameter does not need to be set. The base
station controller uses the O&M IP address
and URL as the source and destination IP
addresses, respectively, for routine
certificate management.
If this parameter is set to CFG_UPD_SIP,
the UPDSIP parameter needs to be set. The
base station controller uses UPDSIP and
URL as the source and destination IP
addresses, respectively, for routine
certificate management.
Figure 4-23 CANAME configuration
Table 4-25 lists the data to be prepared for a device certificate (the CERTMK MO).

SingleRAN

Name
Certificate File CERTMK.APPCERT l If an operator-issued device certificate is

the base station controller and U2020,
two CERTMK MOs must be configured
to specify an operator-issued device
certificate, respectively. For operator-
issued device certificates, this parameter
is set to OPKIDevCert.cer. For
Huawei-issued device certificates, this
parameter is set to usercert.pem or
hwusercert.pem.
only one CERTMK MO needs to be
configured to specify a Huawei-issued
device certificate. This parameter is set
to usercert.pem or hwusercert.pem
accordingly. Users cannot modify or
remove this MO.
Table 4-26 lists the data to be prepared for an active certificate (the APPCERT MO). Active
certificates are device certificates that are currently used by a base station controller.

Name
Application APPCERT.APPTYPE This parameter must be set to SSL.

Type
Certificate File APPCERT.APPCERT l If an operator-issued device certificate is

this parameter must be set to
OPKIDevCert.cer.
this parameter must be set to
usercert.pem or hwusercert.pem.
Table 4-27 lists the data to be prepared for a trust certificate (the TRUSTCERT MO).

SingleRAN

Name
Certificate File TRUSTCERT.CERTNA An operator's trust certificate and a Huawei

Name ME trust certificate must be configured. For the
Huawei trust certificate, set this parameter
to rootca.pem on the base station controller
side. For the operator's trust certificate, set
this parameter to CN.pem when automatic
certificate application is used. The value of
CN must be the same as that in the Subject
field of the trust certificate.
If the operator's CA system has a multi-
certificate chain must be configured.
CERTCHKTSK MO).
Name
Checking CERTCHKTSK.PERI The default value is recommended.

Period (Days) OD
Alarm CERTCHKTSK.ALMR The default value is recommended.

Threshold NG
(Days)
Update Method CERTCHKTSK.UPDA The recommended value of this parameter is

TEMETHOD CMP.
(Optional) Prepare CRL data if the base station controller needs to obtain CRL information
from the CA. Table 4-29 lists the data to be prepared for a CRL (the CRL MO).

Name
CRL File Name CRL.CERTNAME -
(Optional) Prepare data related to CRL usage policies. Table 4-30 lists the data to be prepared
for these policies (the CRLPOLICY MO).

SingleRAN

Name
CRL Using CRLPOLICY.CRLPOL The default value of this parameter is

Policy ICY NOVERIFY. Operators can set this
parameter based on site requirements.
(Optional) Prepare data related to a periodic CRL download task. Table 4-31 lists the data to
be prepared for the task (the CRLTSK MO).

Name
Task ID CRLTSK.TSKID -
IP Address CRLTSK.IP Set this parameter to the IP address of the

certificate & CRL database.
Access Method CRLTSK.CRLGETME The recommended value of this parameter is

THOD LDAP. Set this parameter to FTP only
when the peer device does not support
LDAP.
Port No. CRLTSK.PORT -
User Name CRLTSK.USR -
Password CRLTSK.PWD -
File Name CRLTSK.FILENAME -
Using CRL's CRLTSK.ISCRLTIME If this parameter is set to ENABLE, the

Next Update base station controller downloads a CRL
when the next update time arrives.
CRL Updating CRLTSK.PERIOD This parameter must be set when

Period(h) ISCRLTIME is set to DISABLE.
Source IP CRLTSK.SIP This parameter indicates the source IP

address to download a CRL. When the IP
address is set to 0.0.0.0, the system
automatically uses the IP address of the
OMU board as the source IP address to
obtain the updated CRL from the CRL
server.
Distinguish CRLTSK.SEARCHDN This parameter must be set when

Name CRLGETMETHOD is set to LDAP.

SingleRAN

Name
Connection CRLTSK.CONNMODE This parameter indicates whether to use

Mode SSL connections. This parameter takes
effect only when CRLGETMETHOD is set
to LDAP.
Authenticate CRLTSK.AUTHPEER This parameter indicates whether to

Peer authenticate the peer certificate when the
SSL connections are used. This parameter
takes effect only when the
CRLGETMETHOD parameter is set to
LDAP.
If this parameter is set to authenticate the
peer certificate, ensure that the NEs and
CRL server have been correctly configured
with the CA trust certificates and device
certificates.
DLD CERTFILE in MML configurations).

Name
FTP Server IP IP -
User Name USR -
Password PWD -
Source File SRCF -

Name


recommended value of this parameter is
Yes(Guage).
(Optional) Prepare data to manually trigger a CMPv2-based certificate application. Table

4-33 lists the data to be prepared for applying for a device certificate based on CMPv2 (the
REQ DEVCERT in MML configurations).

SingleRAN
Table 4-33 Data to be prepared for applying for a device certificate based on CMPv2
Name
Authority Name
Certificate File CERTMK.APPCERT -

Name
(Optional) Prepare data to manually trigger a CMPv2-based certificate update. Table 4-34
lists the data to be prepared for updating a device certificate (the UPD DEVCERT in MML
configurations) based on CMPv2.
Table 4-34 Data to be prepared for updating a device certificate based on CMPv2
Name
Certificate File CERTMK.APPCERT This parameter specifies a certificate to be

Name updated.

YES(YES).
Function Activation
Perform the following steps to activate an operator-issued device certificate on the base
station controller side:
Step 1 Run the MOD CERTREQ command to modify configurations of a certificate request
template.
Step 2 Run the ADD CA command to add an operator's CA.
Step 3 Run the LST APPCERT command to check whether the base station controller has been
configured with a device certificate for identity authentication. If "Certificate File Name" in
the command output is usercert.pem, the base station has a preconfigured Huawei-issued
device certificate. Go to the next step. If "Certificate File Name" in the command output is
hwusercert.pem, the base station has a preconfigured Huawei-issued device certificate that is
bound with the ESN of the OMU board. Go to step 5.
Step 4 Perform the following steps to manually configure an operator-issued device certificate for
the base station controller on the U2020:
1. Run the CRE CERTREQFILE command to generate the certificate request file.

SingleRAN
2. Run the ULD CERTFILE command to send the local certificate request file to the
U2020 to apply for the device certificate.
3. The U2020 sends the certificate request to the operator's CA. You can manually operate
the U2020 to submit the certificate request file to the operator's CA for an operator-
issued device certificate. Then, the CA returns the operator-issued device certificate to
the U2020 by manual operation. The certificate request file and operator-issued device
certificate are saved in the following directory of the U2020: /export/home/sysm/
ftproot/ftptmp.
4. Run the DLD CERTFILE command to download the operator's root certificate from the
U2020.
5. Run the ADD TRUSTCERT command to add an operator's trust certificate.
6. Run the DLD CERTFILE command to download the operator-issued device certificate
from the U2020.
7. Run the ADD CERTMK command to add the device certificate to the base station
controller.
8. Go to step 6.
Step 5 Run the REQ DEVCERT command to apply an operator-issued device certificate for the
base station controller.
NOTE
If the certificate application succeeds, running the REQ DEVCERT command will return a message
about successful execution. You can run the DSP CERTMK command to query whether a certificate
has been applied.
Step 6 On the U2020, choose Security > Certificate Authentication Management > Certificate
Management. In the displayed interface, click Test to check whether SSL connection can be
established between the base station controller and the U2020.
Bidirectional authentication is used for SSL certificate testing. That is, the base station
controller and U2020 authenticate the device certificates of each other. The SSL certificate
testing result reflects whether the certificates can be used.
Step 7 Run the MOD APPCERT command to modify configurations of an active certificate.
Step 8 Run the SET CERTCHKTSK command to set a periodic certificate validity check task.
Step 9 (Optional) Run the DLD CERTFILE command to download a CRL from the operator's
certificate & CRL database.
Step 10 (Optional) Run the ADD CRL command to add a CRL.
Step 11 (Optional) Run the SET CRLPOLICY command to set a CRL usage policy.
Step 12 (Optional) Run the ADD CRLTSK command to add a periodic CRL download task.
----End
In addition to the preceding steps, perform the following step to manually trigger a certificate
update:
Step 1 Run the UPD DEVCERT command to set information about a certificate update. After the
setting takes effect, a CMPv2-based certificate update procedure is triggered.
----End

SingleRAN

certificate on the base station controller side.
LOCALIP="10.120.20.188";
//Adding the operator's CA
//If the base station controller can access the CA only through an external
network, you are advised to set the virtual IP address of the base station
controller in the external network for certificate application and update. The
URL="http://10.88.88.88:80/pkix/", SIGNALG=SHA256, MODE= CFG_UPD_SIP,
UPDSIP="10.120.20.188";
//Setting information required for the base station controller to apply for an
operator-issued device certificate based on CMPv2 when the application needs to
be manually triggered
REQ DEVCERT: CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd, CN=eca1",
APPCERT="OPKIDevCert.cer";
//Adding the active certificate
MOD APPCERT: APPTYPE=IKE, APPCERT="OPKIDevCert.cer";
SET CERTCHKTSK: PERIOD=7, ALMRNG=30, UPDATEMETHOD=CMP;
the U2020.)
DLD CERTFILE: CT=CRL, SRCF="bsc.crl", DSTF="bsc.crl", IP="10.120.86.86",
USR="admin";
//(Optional) Loading the CRL file
ADD CRL: CERTNAME="bsc.crl";
SET CRLPOLICY: CRLPOLICY= NOVERIFY;
ADD CRLTSK: TSKID=0, IP="10.120.86.86", CRLGETMETHOD=LDAP, USR="admin",
PWD="*****", FILENAME="bsc.crl", ISCRLTIME=DISABLE, PERIOD=24;
//In addition, the following configuration is required to manually trigger a
certificate update:
UPD DEVCERT: APPCERT="OPKIDevCert.cer",REKEY=YES;

Step 1 Run the RMV CA command to remove the CA.
Step 2 (Optional) Run the RMV CRLTSK command to remove the task of automatically updating
CRL whose CRLGETMETHOD is set to LDAP.
----End
4.4.6.3 Activation Observation

Step 1 Check the status of device certificates.
Run the MML command DSP APPCERT and check the values of the Certificate File
Name, Issuer, Common Name, and Status parameters in the query result. If the values of
Certificate File Name, Issuer, and Common Name are correct and the value of Status is
Normal, the device certificate has been loaded to the base station controller.
The following is an example.

SingleRAN
Step 2 Check the status of trust certificates.

Run the MML command DSP TRUSTCERT and check the value of Status in the query
result. If Normal is displayed, the trust certificate has been loaded to the base station
controller.
Step 3 (Optional) Check the CRL status.

Run the MML command DSP CRL and check the value of Status in the query result. If
Normal is displayed, the CRL has been loaded to the base station controller.

SingleRAN
----End
4.4.7 Deployment of PKI on the eCoordinator

deploy the PKI feature on the eCoordinator.
Figure 4-24 Example of the secure networking for the eCoordinator

Prepare the following data before using the U2020 to manually configure an operator-issued
device certificate for the eCoordinator:
l Data for certificate requests
l Data for device certificates
l Data for active certificates
l Data for trust certificates
l Data for periodic certificate validity checks

SingleRAN
l Data for CRLs

l (Optional) Data for CRL usage policies
l (Optional) Data for periodic CRL download tasks
l (Optional) Data for downloading certificate files
You can set the parameter based on site requirements. Table 4-35 lists the data to be prepared
for a certificate request template (the CERTREQ MO in MML configurations).

Name
Common Name COMMNAME The common name can only be the

electronic serial number (ESN).
Enumeration values such as MAC and IP
are not supported. Upon the generation of a
certificate request file, the value of the ESN
is used as the common name of the
certificate request file.
Common Name USERADDINFO -

Additional Info.
Country COUNTRY -
Organization ORG -
Organizational ORGUNIT -
Unit
State or STATEPROVINCENA -
Province ME
Locality LOCALITY -
Key Usage KEYUSAGE -
Signature SIGNALG SHA256 is recommended.

Algorithm MD5 is not recommended for use because it
of MD5. If the signature algorithm is set to
or updates.
Key Size KEYSIZE -

SingleRAN

Name
Local Name LOCALNAME If this parameter is not set, the value of the
Common Name field in a certificate is used
(for example,
03021377001000001.huawei.com). If this
parameter is set, the value of this parameter
is the configured value.
Local IP LOCALIP -
Table 4-36 lists the data to be prepared for a device certificate (the CERTMK MO in MML
configurations).

Name
Certificate File APPCERT l If an operator-issued device certificate is

the eCoordinator and U2020, two
CERTMK MOs must be configured to
specify an operator-issued device
certificate, respectively. This parameter
must be set to OPKIDevCert.cer for the
operator-issued device certificate and
eCoordinator_Certificate.cer for the
Huawei-issued device certificate.
the eCoordinator and U2020, only one
CERTMK MO needs to be configured
to specify a Huawei-issued device
certificate. This parameter needs to be
set to eCoordinator_Certificate.cer
accordingly. Users cannot modify or
remove this MO.
Table 4-37 lists the data to be prepared for an active certificate (the APPCERT MO in MML
configurations). Active certificates are device certificates that are currently used by the
eCoordinator.

SingleRAN

Name
Application APPTYPE This parameter must be set to SSL because

Type the eCoordinator does not support IKE
currently.
Certificate File APPCERT The certificate file name must have been
Name configured in a CERTMK MO.
Table 4-38 lists the data to be prepared for a trust certificate (the TRUSTCERT MO in MML
configurations).

Name
Certificate File CERTNAME l An operator's trust certificate and a

Name Huawei trust certificate must be
configured. For the Huawei trust
certificate, set this parameter to
rootca.pem. For the operator's trust
certificate, it is recommended that this
parameter be set to OperationCA.cer.
l If the operator's CA system has a multi-
certificate chain must be configured.
CERTCHKTSK MO in MML configurations).

Name
Checking PERIOD The default value is recommended.

Period
Alarm ALMRNG The default value is recommended.

Threshold
Update Method UPDATEMETHOD The default value is recommended. The

eCoordinator currently does not support
CMP.

SingleRAN
(Optional) If the eCoordinator needs to obtain CRL information from the CA, the following
data must be prepared:
l Data to be prepared for a CRL (the CRL MO in MML configurations). For details, see
Table 4-40.
l Data to be prepared for CRL usage policies (the CRLPOLICY MO in MML
configurations). For details, see Table 4-41.
l Data to be prepared for a periodic CRL download task (the CRLTSK MO in MML
configurations). For details, see Table 4-42.

Name
CRL File Name CERTNAME -

Name
CRL Using CRLPOLICY The default value of this parameter is

Policy NOVERIFY. Operators can set this
parameter based on site requirements.

Name
IP Address IP Set this parameter to the IP address of the

CRL server.
User Name USR -
Password PWD -
File Name FILENAME -
Using CRL's ISCRLTIME If this parameter is set to ENABLE, the

Next Update eCoordinator downloads a CRL when the
next update time arrives.
CRL Updating PERIOD This parameter must be set when

Period (h) ISCRLTIME is set to DISABLE.
Access Method CRLGETMETHOD The recommended value of this parameter is

FTP. Value LDAP is currently not
supported by the eCoordinator.

SingleRAN

Name
Task ID TSKID -
Source IP SIP If this parameter is not set, the eCoordinator

uses the O&M IP address as the source IP
address to update a CRL.
CERTFILE MO in MML configurations).

Name
Source File SRCF -

Name

FTP Server IP IP -
User Name USR -
Password PWD -

recommended value of this parameter is
Yes(Guage).

LOCALIP="10.20.20.188";
//Generating a certificate request file
CRE CERTREQFILE:FILENAME="ECO6910Cert.req",REQMODE=NEW;
//Uploading the certificate request file
ULD
CERTFILE:CT=CERTREQ,SRCF="ECO6910Cert.req",DSTF="ECO6910Cert.req",IP="10.86.86.86"
,USR="admin",PWD="*****";
//The administrator applies for a device certificate on the U2020 based on the certificate
request file. For details, see section "Manually Applying For a Device Certificate" in U2020
MBB Network Management System Product Documentation.

SingleRAN
//Downloading an operator's root certificate from an FTP server (assume that the
FTP server is deployed on the U2020, indicating that the IP address of the FTP
server is the same as that of the U2020)
DLD
CERTFILE:CT=TRUSTCERT,SRCF="OperationCA.cer",DSTF="OperationCA.cer",IP="10.86.86.8
6",USR="admin",PWD="*****";
//Adding an operator's root certificate as the trust certificate
ADD TRUSTCERT:CERTNAME="OperationCA.cer";
//Downloading an operator-issued device certificate from the CA (assume that the
device certificate is saved on the FTP server of the U2020)
DLD CERTFILE:CT=DEVCERT,SRCF="/Cert/
OPKIDevCert.cer",DSTF="OPKIDevCert.cer",IP="10.86.86.86",USR="admin",PWD="*****";
//Adding a device certificate
ADD CERTMK:APPCERT="OPKIDevCert.cer";
//On the U2020, choose Security > Certificate Authentication Management >
Certificate Management. In the certificate management window, select the
requested operator-issued device certificate. Click Test to test whether an SSL
connection can be established between the NE and the U2020 by using this device
certificate.
//Modifying configurations of an active certificate
MOD APPCERT:APPTYPE=SSL,APPCERT="OPKIDevCert.cer";
SET CERTCHKTSK:PERIOD=7,ALMRNG=30,UPDATEMETHOD=CMP;
the U2020.)
DLD
CERTFILE:CT=CRL,SRCF="ECO.crl",DSTF="ECO.crl",IP="10.86.86.86",USR="admin",PWD="**
***";
//(Optional) Loading the CRL file
ADD CRL:CERTNAME="ECO.crl";
SET CRLPOLICY:CRLPOLICY=NOVERIFY;
ADD
CRLTSK:TSKID=0,IP="10.86.86.86",USR="admin",PWD="*****",FILENAME="ECO.crl",ISCRLTI
ME=DISABLE;


Perform the following steps to observe whether the PKI feature has been activated:
Step 1 Run the MML command DSP APPCERT to check the status of device certificates. If the
values of Certificate File Name, Issuer, and Common Name are correct and the value of
Status is Normal, the device certificate has been loaded to the eCoordinator.
Step 2 Run the MML command DSP TRUSTCERT to check the status of trust certificates. If the
value of Status is Normal in the query result, the trust certificate has been loaded to the
eCoordinator.
Step 3 (Optional) Run the MML command DSP CRL to check the CRL status. If the value of Status
is Normal in the query result, the CRL has been loaded to the eCoordinator.
----End
4.4.8 Deployment of PKI on a Board with eCPRI Ports

SingleRAN

Before this function is enabled, engineering personnel must obtain the requirements for
applying for certificates from the CA by the BBU proxy from the CA maintenance engineer.
To deploy the PKI feature on an eCPRI port, prepare the following data.
Table 4-44 Parameters in the MOD APPCERT command

Name
RRU Certificate APPCERT.RRUCERTR Set this parameter to ON(On).

Request Switch EQSW

//Turning on the switch for the AAU to apply for an operator-issued device
certificate
MOD APPCERT: APPTYPE=IKE, APPCERT="eNodeBCert.pem", RRUCERTREQSW=ON;

//Turning off the switch for the AAU to apply for an operator-issued device
certificate
MOD APPCERT: APPTYPE=IKE, APPCERT="eNodeBCert.pem", RRUCERTREQSW=OFF;


Type
Single CME Management > CME Guidelines > Getting Started with
configuration the CME > Introduction to Data Configuration Operations


SingleRAN

Perform the following operations to check whether an operator-issued device certificate has
been successfully applied for:
Step 1 Run the SET RRUSECPOLICY command to disable Huawei certificate authentication for
an RRU.
Step 2 Check whether the eCPRI connection is normal.
l Initiate a voice service and a data service and then check whether the two services are
running normally.
l Check whether the corresponding base station is online on the topology view of the
U2020.
----End
4.4.9 Reconfiguration
Reconfiguration of CA Name
In Certificate Authority Name, the S and ST fields are regarded as the same field. Services
can be properly provided if the S field is used at one end but the ST field is used at the other
end.
To change the S field to the ST field, perform the following steps:
//Removing the original CA configuration
RMV CA:CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd, CN=eca1";
//Adding a CA
ADD CA:CANAME="C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=eca1",
URL="http://10.88.88.88:80/pkix/";
Estimation of Certificate Reconfiguration Impact

If the following commands are involved during reconfiguration, the base station estimates
whether services will be affected after the reconfiguration. For details, see 4.1.3.7 Estimation
of Certificate Reconfiguration Impact.
l MOD CERTREQ
l MOD CA
l MOD APPCERT
l MOD CERTMK
Activation of Automatic Certificate Application After a CA Change (in Base

Station Deployment/IKE negotiation Failure Scenarios)
If the RA name is specified by the CA.CANAME parameter, remove this CA record and then
reconfigure a correct one.
MML command examples are as follows:
//Assuming that RANAME is set to C = AU, S = Some-State, O = Internet Widgits Pty Ltd,
CN = eca2, and CANAME is set to C = AU, S = Some-State, O = Internet Widgits Pty Ltd,
CN = eca1
//A CA has been configured.

SingleRAN
URL="http://10.88.88.88:80/pkix/", SIGNALG=SHA256, MODE=
CFG_INIT_UPD_ADDR, UPDSIP="10.31.31.188",INITREQURL="http://10.89.89.89:80/
Run the following commands:
//Adding a CA
ADD CA: CANAME="C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN =
eca1",RANAME="C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca2",
//Turning on the CA switch
MOD CERTMK:APPCERT="opki1.cer",CASW=ON,CANAME="C = AU, S = Some-State, O =
Internet Widgits Pty Ltd, CN = eca1";
//Removing the original CA configuration
RMV CA:CANAME="C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=eca2";
//Turning off the CA switch
MOD CERTMK:APPCERT="opki1.cer",CASW=OFF;
//Turning on the automatic certificate reapplication switch
SET CERTCHKTSK:PERIOD=7, ALMRNG=30, UPDATEMETHOD=CMP, AUTOREAPPLYSW = ON;
4.4.10 Network Monitoring

None

SingleRAN
PKI Feature Parameter Description 5 NE Supporting PKI Redundancy
5 NE Supporting PKI Redundancy
5.1 Principles
To improve the reliability of PKI-based secure networks, PKI redundancy is introduced to
both the base station and base station controller. The eCoordinator does not support PKI
redundancy.
To achieve PKI redundancy, two PKI servers must be deployed on the network. There should
be reachable routes between the base station/base station controller and the two PKI servers.
In addition, the following conditions should be met:
l The two PKI servers have the same CANAME and root certificate or certificate chain
and synchronize certificate management databases between them.
l The two CAs must have different IP addresses, and so do active and standby CRL
servers.
Every time before certificate application, certificate update, and CRL acquisition, the base
station or base station controller first initiates a session with the active PKI server. If the
session fails, the base station or base station controller reinitiates a session with the standby
PKI server. This mechanism ensures successful certificate applications and updates as well as
CRL acquisitions.

SingleRAN
Figure 5-1 Working principles of PKI redundancy
The following parameters specify the URL of the standby CA on the base station and base
station controller sides:
l CA.SLVURL
l CA.SLVINITREQURL
The following parameters specify the login information of the standby CRL server on the base
station and base station controller sides:
l CRLTSK.SLVIP
l CRLTSK.SLVPORT
l CRLTSK.SLVUSR
l CRLTSK.SLVPWD
During certificate updates or CRL acquisitions, the base station/base station controller reports
ALM-26842 Automatic Certificate Update Failed only when the sessions between the base
station/base station controller and both the active and standby PKI servers fail.
PKI redundancy has the following application limitations: PKI redundancy is not supported
during base station deployment by PnP. The operator must ensure that the active PKI server
works properly during base station deployment by PnP.
5.2.1 Benefits
This feature improves networking reliability
5.2.2 Impacts
Network Impacts
None

SingleRAN
Function Impacts
None
5.3 Requirements
5.3.1 Licenses
The following table lists the licenses controlling PKI Redundancy.
Feature Feature Name Model License NE Sales
ID Control Item Unit
Name
GBFD-160 BTS Supporting LGB3BTS BTS Supporting BTS Per BTS

210 PKI PKIR PKI
Redundancy Redundancy
(per BTS)
WRFD-16 NodeB LQW9PKI NodeB NodeB Per NodeB

0275 Supporting PKI RD01 supporting PKI
Redundancy redundancy (per
NodeB)
LOFD-070 eNodeB LT1SESPK eNodeB eNodeB Per

212 Supporting PKI IR00 Supporting PKI eNodeB
Redundancy Redundancy(F
DD)
MLOFD-0 eNodeB ML1SESP eNodeB eNodeB Per

70212 Supporting PKI KIR00 Supporting PKI eNodeB
Redundancy redundancy(NB
-IoT)
TDLOFD- eNodeB LT1SENB eNodeB eNodeB Per

070212 Supporting PKI SPR00 Supporting PKI eNodeB
Redundancy Redundancy(T
DD)
GBFD-160 BSC LGMIPKI BSC BSC6900 Per TRX

208 Supporting PKI RED Supporting PKI and
Redundancy redundancy (per BSC6910
TRX)
WRFD-16 RNC LQW1PKI RNC BSC6900 Per Erl

0277 Supporting PKI REDE supporting PKI and
Erl)
WRFD-16 RNC LQW1PKI RNC BSC6900 Per Mbps

0277 Supporting PKI REDM supporting PKI and
Mbps)

SingleRAN
5.3.2 Software
feature documents.
5.3.2.1 GBFD-160210 BTS Supporting PKI Redundancy
Name
BTS Supporting None PKI

PKI

None
5.3.2.2 GBFD-160208 BSC Supporting PKI Redundancy
Name
BSC None PKI

Supporting PKI

None
5.3.2.3 WRFD-160275 NodeB Supporting PKI Redundancy
Name
NodeB PKI None PKI

Support

None

SingleRAN
5.3.2.4 WRFD-160277 RNC Supporting PKI Redundancy
Name
RNC None PKI

Supporting PKI

None
5.3.2.5 LOFD-070212 eNodeB Supporting PKI Redundancy
Name
Public Key None PKI

Infrastructure
(PKI)

None
5.3.2.6 MLOFD-070212 eNodeB Supporting PKI Redundancy
Name
Public Key None PKI

Infrastructure
(PKI)

None

SingleRAN
5.3.2.7 TDLOFD-070212 eNodeB Supporting PKI Redundancy
Name
Public Key None PKI

Infrastructure
(PKI)

None
5.3.2.8 FBFD-010023 Security Mechanism (gNodeB Supporting PKI Redundancy)
None

None
5.3.3 Hardware
For details, see 4.3.3 Hardware.
5.3.4 Networking
l Two PKI servers are deployed on the operator's network. For the requirements for PKI
servers, see 4.3.4 Others.
l The two PKI servers have the same CA name and root certificate or certificate chain and
synchronize certificate management databases between them.
l There are reachable routes between the base station/base station controller and the two
PKI servers.
5.4.1 Precautions
Before deploying the PKI redundancy feature, engineering personnel need to collect the
following information besides that listed in 4.4.2 Precautions.

SingleRAN
Items to Be Collected Required Parameter on the Base Station or Base

Station Controller Side
URL of the standby CA CA.SLVURL

(Optional) CA.SLVINITREQURL
(Optional) IP address of the CRLTSK.SLVIP

standby CRL server
(Optional) user name for logging CRLTSK.SLVUSR

in to the standby CRL server
(Optional) password for logging CRLTSK.SLVPWD

in to the standby CRL server
(Optional) port number of the CRLTSK.SLVPORT

standby CRL server
5.4.2 Deployment of PKI Redundancy on the eGBTS/NodeB/

eNodeB/gNodeB/Multimode Base Station
deploy the PKI redundancy feature on the GBTS/eGBTS/NodeB/eNodeB/gNodeB/multimode
base station. A UMDU/MDUC can also be used in a co-MPT multimode base station in the
secure networking shown in Figure 5-2. However, a UMDU/MDUC cannot be used in a
separate-MPT multimode base station.
Figure 5-2 Example of the secure networking for the eGBTS/NodeB/eNodeB/gNodeB/

multimode base station

Compared with the data to be prepared described in section 4.4.3.1 Data Preparation the
following lists the additional data for preparation.

SingleRAN
The following table lists the additional data to be prepared for the CA (the CA MO).
Parameter Name Parameter ID Setting Notes
Slave Certificate CA.SLVURL This parameter needs to be set

Authority URL when PKI redundancy is
enabled.
Slave CA URL CA.SLVINITREQURL This parameter needs to be set

During Site when PKI redundancy is
Deployment enabled.
(Optional) The following table lists the additional data to be prepared for a periodic CRL
download task.
Parameter Name Parameter ID Setting Notes
Slave IP Address CRLTSK.SLVIP This parameter needs to be set

to the IP address of the standby
CRL server when PKI
redundancy is enabled.
Slave User Name CRLTSK.SLVUSR This parameter needs to be set

when PKI redundancy is
enabled.
Slave Password CRLTSK.SLVPWD This parameter needs to be set

enabled.
Slave Port No. CRLTSK.SLVPORT This parameter can be set only

enabled.

For details, see 4.4.3.2 Using MML Commands. The following describes the differences in
configurations.
In the PKI redundancy scenario, the configurations of the CA and periodic CRL download
task are as follows:
through the intranet and O&M data is protected by IPsec, you are advised to set
the source IP addresses for certificate application and update to an interface IP
address and an O&M IP address (for example, 10.31.31.188), respectively. The
UPDSIP="10.31.31.188", INITREQURL="http://10.89.89.89:80/
pkix/",INITREQSIP="10.20.20.188",SLVURL="http://10.98.98.98:80/
pkix/",SLVINITREQURL="http://10.99.99.99:80/pkix/";
through the intranet and O&M data is not protected by IPsec, you are advised to

SingleRAN
set the source IP addresses for certificate application and update to an

interface IP address and an intranet IP address(for example, 10.45.45.45),
respectively. The following is an example:
UPDSIP="10.45.45.45", INITREQURL="http://10.89.89.89:80/
pkix/",INITREQSIP="10.20.20.188",SLVURL="http://10.98.98.98:80/
pkix/",SLVINITREQURL="http://10.99.99.99:80/pkix/";
//If the base station can access the CA only through an external network, you are
advised to set the source IP addresses for both certificate application and
update to interface IP addresses. The following is an example:
ADD CA: CANAME="C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN =
eca1",URL="http://10.88.88.88:80/
pkix/",SIGNALG=SHA256,MODE=CFG_INIT_UPD_ADDR,UPDSIP="10.20.20.188",INITREQURL="htt
p://10.89.89.89:80/pkix/",INITREQSIP="10.20.20.188",SLVURL="http://10.98.98.98:80/
pkix/",SLVINITREQURL="http://10.99.99.99:80/pkix/",CERTREQSW=DEFAULT;
//(Optional) Adding a periodic CRL download task
ADD CRLTSK: IP="10.86.86.86", USR="admin", PWD="*****", FILENAME="eNodeB.crl",
ISCRLTIME=DISABLE, PERIOD=24, TSKID=0, CRLGETMETHOD=FTP, SLVIP="10.96.96.96",
SLVUSR="admin2", SLVPWD="*****";

The certificate update and CRL file obtaining succeed when the active PKI server is faulty
and the standby PKI server is normal. You can run MML commands to query the status of the
device certificates and CRL files. If the results shown in the following figures are displayed,
PKI redundancy functions properly.
Run the MML command DSP CERTMK. In the command output, CA URL Last Used
indicates the URL of the standby CA, and Last Update Time of Certificate indicates the
time of the latest certificate update.
Step 2 Check the status of CRL files.
Run the MML command DSP CRL. In the command output, CRL Server IP Address Last
Used indicates the IP address of the standby CRL, and Last Update Time of CRL indicates
the time of the latest CRL obtaining.
----End

SingleRAN
5.4.3 Reconstruction from a PKI-based Secure Network to a PKI

Redundancy Network on the eGBTS/NodeB/eNodeB/gNodeB/
Multimode Base Station
This section uses the networking illustrated in Figure 5-3 as an example to describe the
reconstruction requirements and reconfiguration procedure when a PKI-based secure network
is reconstructed into a PKI redundancy network on the eGBTS/NodeB/eNodeB/gNodeB/
multimode base station. A UMDU can also be used in a co-MPT multimode base station in
the secure networking shown in Figure 5-3. However, a UMDU/MDUC cannot be used in a
separate-MPT multimode base station.
Figure 5-3 Example of reconstructing a PKI-based secure network into a PKI redundancy
network on the eGBTS/NodeB/eNodeB/gNodeB/multimode base station

SingleRAN
General Procedure
Network Deployment and Information Collection

l A standby PKI server has been deployed on the network.
l The active and standby PKI servers have the same CA name and root certificate or
certificate chain and synchronize certificate management databases between them. There
should be reachable routes between the base station and the two PKI servers.
l Engineering personnel collect information about the standby PKI server, including the
URL of the standby CA, URL of the CA which issues the certificate during deployment,
IP address, user name, password, and port number of the standby CRL server.
Checking the Base Station Environment

l The base station meets the hardware requirements described in section 4.3.3 Hardware.
l The license for the PKI redundancy feature has been activated on the base station.
Data Planning
In additional to the original configuration data, you need to configure data for the standby CA
and standby CRL server.

SingleRAN
The following table lists the data to be prepared for the standby CA.

Name
Slave CA.SLVURL This parameter needs to be set when PKI

Certificate redundancy is enabled.
Authority URL
Slave CA URL CA.SLVINITREQURL

During Site
Deployment
(Optional) The following table lists the data to be prepared for a periodic CRL download task.

Name
Slave IP CRLTSK.SLVIP This parameter needs to be set to the IP

Address address of the standby CRL server when
PKI redundancy is enabled.
Slave User CRLTSK.SLVUSR This parameter needs to be set when PKI

Name redundancy is enabled.
Slave Password CRLTSK.SLVPWD
Slave Port No. CRLTSK.SLVPORT
5.4.3.2 Data Configuration
Preparing the Incremental Script

An incremental script is generated based on data of existing base stations and includes
configuration modifications.
For details about how to modify PKI redundancy configurations, see 4.4.3.2 Using MML
Commands.
Downloading the Modified Data
1. On the main menu of the U2020, click in the upper left corner.
2. On the Application Center tab page, double-click the CME icon to start the CME.
3. On the CME, choose CM Express > Planned Area, and click to export the
incremental script.
4. In the Export Incremental Scripts dialog box, choose a specific base station controller
to which the script is exported, specify Output Path and Script Executor Operation,
and click OK.

SingleRAN
5. On the displayed Script Executor page, observe the export progress.

For details, see 5.4.2.3 Activation Observation.
5.4.4 Deployment of PKI Redundancy on the Base Station

Controller
PKI redundancy on the base station controller helps improve the reliability of the device
certificate and CRL update. Therefore, the standby CA and CRL servers must be configured
before PKI redundancy is enabled.

Compared with the data to be prepared described in section 4.4.6.1 Data Preparation the
following lists the additional data for preparation.
The following table lists the additional data to be prepared for the CA (the CA MO).

Name

Authority URL
(Optional) The following table lists the additional data to be prepared for a periodic CRL
download task (the CRLTSK MO).

Name


Slave Password CRLTSK.SLVPWD This parameter needs to be set when PKI

Slave Port No. CRLTSK.SLVPORT This parameter can be set only when PKI

For details, see 4.4.6.2 Using MML Commands. The following describes the differences in
configurations.

SingleRAN

//If the base station controller can access the CA only through an external
network, you are advised to set the virtual IP address of the base station
controller in the external network for certificate update. The following is an
example:
URL="http://10.88.88.88:80/pkix/", SIGNALG=SHA256, MODE= CFG_UPD_SIP,
UPDSIP="10.120.20.188",SLVURL="http://10.98.98.98:80/pkix/";
//(Optional) Adding a periodic CRL download task
ADD CRLTSK: TSKID=1, IP="10.86.86.86", CRLGETMETHOD=LDAP, PORT=389, USR="admin",
PWD="*****", FILENAME="bsc.crl", ISCRLTIME=ENABLE, SIP="10.120.20.188",
SLVIP="10.86.86.90", SLVPORT=389, SLVUSR="test", SLVPWD="*****", SEARCHDN="C =
AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca1";

The certificate update and CRL file obtaining succeed when the active PKI server is faulty
and the standby PKI server is normal. You can run MML commands to query the status of the
device certificates and CRL files. If the results shown in the following figures are displayed,
PKI redundancy functions properly.
Run the MML command DSP CERTMK. In the command output, CA URL Last Used
indicates the URL of the standby CA, and Last Update Time of Certificate indicates the
time of the latest certificate update.
Step 2 Check the status of CRL files.
Run the MML command DSP CRL. In the command output, CRL Server IP Address Last
Used indicates the IP address of the standby CRL, and Last Update Time of CRL indicates
the time of the latest CRL obtaining.
----End
5.4.5 Reconstruction from a PKI-based Secure Network to a PKI

Redundancy Network on the Base Station Controller
This section uses the networking illustrated in Figure 5-4 as an example to describe the
reconstruction requirements and reconfiguration procedure when a PKI-based secure network
is reconstructed into a PKI redundancy network on the base station controller.

SingleRAN
Figure 5-4 Example of reconstructing a PKI-based secure network into a PKI redundancy
network on the base station controller

SingleRAN
General Procedure
Network Deployment and Information Collection

l A standby PKI server has been deployed on the network.
l The active and standby PKI servers have the same CA name and root certificate or
certificate chain and synchronize certificate management databases between them. There
are reachable routes between the base station controller and the two PKI servers.
l Engineering personnel collect information about the standby PKI server, including the
URL of the standby CA, IP address of the standby CRL server, user name, password, and
port number.
Data Planning
In additional to the original configuration data, you need to configure data for the standby CA
and standby CRL server.
The following table lists the data to be prepared for the standby CA.

SingleRAN

Name

Authority URL
(Optional) The following table lists the data to be prepared for a periodic CRL download task.

Name


Slave Password CRLTSK.SLVPWD This parameter needs to be set when PKI

Slave Port No. CRLTSK.SLVPORT This parameter can be set only when PKI
Checking the Base Station Controller Environment

The license for the PKI redundancy feature has been activated on the base station controller.
5.4.5.2 Data Configuration
Preparing the Incremental Script

For details, see section 4.4.6.3 Activation Observation.
For details about how to modify PKI redundancy configurations, see 4.4.6.2 Using MML
Commands.
Downloading the Modified Data
1. On the main menu of the U2020, click in the upper left corner.
2. On the Application Center tab page, double-click the CME icon to start the CME.
3. On the CME, choose CM Express > Planned Area, and click to export the
incremental script.
4. In the Export Incremental Scripts dialog box, choose a specific base station controller
to which the script is exported, specify Output Path and Script Executor Operation,
and click OK.

SingleRAN
5. On the displayed Script Executor page, observe the export progress.

6. After the export is complete, restart the base station controller to make the script take
effect.

For details, see 5.4.4.3 Activation Observation.

None

SingleRAN
PKI Feature Parameter Description 6 NE Supporting Digital Certificate Whitelist Management
6 NE Supporting Digital Certificate Whitelist

Management
6.1 Principles
If no PKI system is deployed on an operator's network, the base station cannot use an
operator-issued device certificate to access the operator's network. In this case, the base
station can use the digital certificate whitelist management function to access the operator's
network. To support the digital certificate whitelist management, both the base station and
SeGW must be Huawei equipment and be preconfigured with Huawei-issued device
certificates. A digital certificate whitelist is a list of Common Name in the Huawei-issued
device certificates preconfigured on the base station and SeGW.
A digital certificate whitelist is configured on the U2020 and then loaded onto the base
station. During IKE negotiation for IPsec tunnel establishment, the base station uses the
digital certificate whitelist to authenticate each piece of equipment that expects to establish an
IPsec tunnel with the base station. The base station can perform IKE negotiation and establish
IPsec tunnels only with the equipment in the whitelist. IPsec tunnels cannot be established
between the base station and any equipment not in the whitelist. The digital certificate
whitelist is used for authentication between base stations only when there are links (for
example, the X2 interface) between them or base stations are cascaded.
Digital certificate whitelist management has the following application limitations:
l Only Huawei-issued device certificates can be used for authentication. Security risks
exist if Huawei-issued device certificates are always used for authentication. For details,
see 4.1.2.1 Device Certificate.
l The digital certificate whitelist management function supports only IKE/IPsec
negotiation and does not support other types of security channels (such as SSL).
6.2.1 Benefits
The base station can use the digital certificate whitelist management function to access the
operator's network.

SingleRAN
6.2.2 Impacts
None
6.3 Requirements
6.3.1 Licenses
Feature Feature Name Model License NE Sales Unit
ID Control Item
Name
GBFD-18 BTS Supporting LGB3BSD BTS Supporting BTS Per BTS

1202 Digital CWM01 Digital
Certificate Certificate
Whitelist Whitelist
Management Management(pe
r BTS)
WRFD-18 NodeB LQW9SD NodeB NodeB Per NodeB

1220 Supporting CWLM01 Supporting
Digital Digital
Whitelist Whitelist
Management Management
(per NodeB)
LOFD-11 eNodeB LT1SDIG eNodeB eNodeB Per eNodeB

1203 Supporting WHI00 Supporting
Digital Digital
Whitelist Whitelist
Management Management(F
DD)
MLOFD- eNodeB ML1SDIG eNodeB eNodeB Per eNodeB

111203 Supporting WHI00 Supporting
Digital Digital
Whitelist Whitelist
Management Management(N
B-IoT)
FOFD-01 IPsec (gNodeB NR0S0IPS IPsec gNodeB Per gNodeB

0080 Supporting EC00
Digital
Certificate
Whitelist
Management)

SingleRAN
6.3.2 Software
feature documents.
6.3.2.1 GBFD-181202 BTS Supporting Digital Certificate Whitelist Management
Name
BTS Integrated None IPsec

IPSec

None
6.3.2.2 WRFD-181220 NodeB Supporting Digital Certificate Whitelist

Management
Name
NodeB None IPsec

Integrated
IPSec

None
6.3.2.3 LOFD-111203 eNodeB Supporting Digital Certificate Whitelist

Management
Name
IPsec None IPsec

SingleRAN

None
6.3.2.4 MLOFD-111203 eNodeB Supporting Digital Certificate Whitelist

Management
Name
IPsec None IPsec

None
6.3.2.5 FOFD-010080 IPsec (gNodeB Supporting Digital Certificate Whitelist

Management)
None

None
6.3.3 Hardware
Base Station Models

GSM 3900 and 5900 series base stations
UMTS l 3900 and 5900 series base stations

l BTS3911E
LTE l 3900 and 5900 series base stations

l BTS3912E
l BTS3911E

SingleRAN
NR l 3900 and 5900 series base stations. 3900 series base stations must be
configured with the BBU3910.
l DBS3900 LampSite and DBS5900 LampSite. DBS3900 LampSite
must be configured with the BBU3910.
Boards
l For an eGBTS, only the Ethernet ports on the UMPT, BBU3910A, and UTRPc support
this function.
l For a NodeB, only the UMPT, BBU3910A, and UTRPc support this function.
l For an LTE FDD eNodeB, only the UMPT, BBU3910A, LMPT, and UTRPc support this
function.
l For a gNodeB, only the UMPT supports this function.
RF Modules
This function does not depend on RF modules.
6.3.4 Others
SeGWs must be Huawei devices and support Digital Certificate Whitelist Management.
6.4.1 When to Use

This feature is recommended when no PKI system is deployed on the network and the
preconfigured Huawei certificates will be used for IKE/IPsec authentication.
6.4.2 Data Configuration

Collect the common names in the preconfigured Huawei-issued device certificates of all base
stations and SeGWs to be connected to the network.
Figure 6-1 shows the process of deploying Digital Certificate Whitelist Management.

SingleRAN
Figure 6-1 Process of deploying Digital Certificate Whitelist Management
The following data must be prepared on the base station side:
Table 6-1 Parameters in the DLD CERTFILE command

Name
FTP Server IP IP Set these parameters based on the site

conditions.
User Name USR
Password PWD
Source File SRCF

Name
Destination File DSTF

Name
Guage Option GA
Certificate Type CT Set this parameter to

CERTWHITELST(CERTWHITELST).

SingleRAN
Table 6-2 Parameters in the ACT CERTWHITELSTFILE command

Name
Digital CERTCFG.CERTWHI Set this parameter based on the site

Certificate TELSTFILENAME conditions.
Whitelist File
Name
Integrity Check CERTCFG.INTEGRIT Set this parameter to ON(On).

Switch YCHECKSW
Integrity Check CERTCFG.FILEPWD Set this parameter based on the site

Password conditions.
Table 6-3 Parameters in the SET CERTCFG command

Name
IKE Check CERTCFG.IKECHECK Set this parameter to ON(On).

Switch SW

You can configure a digital certificate whitelist on the U2020, download it from the U2020 to
a base station, and then activate it. For details, see descriptions in U2020 MBB Network
Management System Product Documentation. This section describes how to activate a digital
certificate whitelist using MML commands on the base station.
//Downloading a digital certificate whitelist from the U2020 to a base station
DLD CERTFILE: IP="192.168.1.1", USR="admin", PWD="*****",
SRCF="certwhitelist.gz", DSTF="certwhitelist.gz",CT=CERTWHITELST;
//Activating the digital certificate whitelist
ACT CERTWHITELSTFILE: CERTWHITELSTFILENAME="certwhitelist.gz",
INTEGRITYCHECKSW=ON, FILEPWD="********";
//Turning on the IKE check switch
SET CERTCFG: IKECHECKSW=ON;

//Turning off the IKE check switch
SET CERTCFG: IKECHECKSW=OFF;


SingleRAN

Type
Single configuration CME Management > CME Guidelines > Getting Started with
the CME > Introduction to Data Configuration Operations
Batch eGBTS CME Management > CME Guidelines > GSM Application
configuration Management > Base Station Related Operations > Importing
and Exporting eGBTS Data for Batch Reconfiguration
Batch NodeB CME Management > CME Guidelines > UMTS Application
configuration Management > NodeB Related Operations > Importing and
Exporting NodeB Data for Batch Configuration

6.4.3 Activation Verification

After Digital Certificate Whitelist Management is deployed, observe the status of IPsec
tunnels using the digital certificate whitelist to determine whether this feature has been
successfully enabled.
Step 1 Run the DSP IPSECSA command to check the IPsec SA status.
Step 2 Check whether services protected by the IPsec tunnel are normal.
l Initiate a voice service and a data service and then check whether the two services are
running normally.
l Check whether the corresponding base station is online on the topology view of the
U2020.
----End

None

SingleRAN
PKI Feature Parameter Description 7 Parameters
7 Parameters
The following hyperlinked EXCEL files of parameter reference match the software version
with which this document is released.
l Node Parameter Reference: contains device and transport parameters.
l gNodeBFunction Parameter Reference: contains all parameters related to radio access
functions, including air interface management, access control, mobility control, and radio
resource management.
NOTE
You can find the EXCEL files of parameter reference for the software version used on the live network
from the product documentation delivered with that version.
FAQ: How do I find the parameters related to a certain feature from parameter
reference?
Step 1 Open the EXCEL file of parameter reference.
Step 2 On the Parameter List sheet, filter the Feature ID column. Click Text Filters and choose
Contains. Enter the feature ID, for example, FBFD-020100.
Step 3 Click OK. All parameters related to the feature are displayed.
----End

SingleRAN
PKI Feature Parameter Description 8 Counters
8 Counters
The following hyperlinked EXCEL files of performance counter reference match the software
version with which this document is released.
l Node Performance Counter Summary: contains device and transport counters.
l gNodeBFunction Performance Counter Summary: contains all counters related to radio
access functions, including air interface management, access control, mobility control,
and radio resource management.
NOTE
You can find the EXCEL files of performance counter reference for the software version used on the live
network from the product documentation delivered with that version.
FAQ: How do I find the counters related to a certain feature from performance counter
reference?
Step 1 Open the EXCEL file of performance counter reference.
Step 2 On the Counter Summary(En) sheet, filter the Feature ID column. Click Text Filters and
choose Contains. Enter the feature ID, for example, FBFD-020100.
Step 3 Click OK. All counters related to the feature are displayed.
----End

SingleRAN
PKI Feature Parameter Description 9 Glossary
9 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

SingleRAN
PKI Feature Parameter Description 10 Reference Documents
10 Reference Documents
l IETF RFC4210, "Internet X.509 Public Key Infrastructure Certificate Management

Protocol (CMP)"
l IETF RFC4211, "Internet X.509 Public Key Infrastructure Certificate Request Message
Format (CRMF)"
l IETF RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile"
l IETF RFC 2585, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP
and HTTP"
l IPsec
l SSL
l Access Control based on 802.1x
l Base Station Supporting Multi-operator PKI
l eCPRI

Pki (Sran15.1 02) PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pki (Sran15.1 02) PDF

Uploaded by

Copyright:

Available Formats

SingleRAN

PKI Feature Parameter Description

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. i

2 About This Document.................................................................................................................. 4

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. ii

4.1.3.5.4 Certificate Update................................................................................................................................................27

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. iii

4.4.5.4 Activation Verification........................................................................................................................................... 70

5 NE Supporting PKI Redundancy............................................................................................. 93

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. iv

6 NE Supporting Digital Certificate Whitelist Management...............................................111

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. v

10 Reference Documents............................................................................................................. 122

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. vi

1.1 SRAN15.1 02 (2019-08-30)

Turned off the RRU certificate request None

1.2 SRAN15.1 01 (2019-06-06)

1.3 SRAN15.1 Draft B (2019-03-18)

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. 1

Added support of operator-issued device Added the RRUCERTREQSW parameter.

Added the disuse statement for the None

Added support for NR by 3900 series None

Deleted the description of the built-in None

1.4 SRAN15.1 Draft A (2018-12-30)

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. 2

Deleted the switch parameter in the Deleted the CERTCHKTSK.ISENABLE

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. 3

2 About This Document

2.1 General Statements

2.2 Applicable RAT

2.3 Features in This Document

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. 4

Feature ID Feature Name Section

LBFD-003010 Public Key Infrastructure (PKI) 4 PKI

TDLBFD-003010 Public Key Infrastructure (PKI)

MLBFD-12000312 Public Key Infrastructure (PKI)

FBFD-010023 Security Mechanism (PKI)

GBFD-113526 BTS Supporting PKI

GBFD-160211 BSC Supporting PKI

WRFD-140210 NodeB PKI Support

WRFD-160276 RNC Supporting PKI

GBFD-160210 BTS Supporting PKI Redundancy 5 NE Supporting PKI

WRFD-160275 NodeB Supporting PKI

WRFD-160277 RNC Supporting PKI Redundancy

LOFD-070212 eNodeB Supporting PKI

TDLOFD-070212 eNodeB Supporting PKI

MLOFD-070212 eNodeB Supporting PKI

FBFD-010023 Security Mechanism (gNodeB

GBFD-181202 BTS Supporting Digital Certificate 6 NE Supporting

LOFD-111203 eNodeB Supporting Digital

MLOFD-111203 eNodeB Supporting Digital

FOFD-010080 IPsec (gNodeB Supporting Digital

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. 5

l Serial number and validity period of the certificate

Huawei base stations/base station controllers/eCoordinators use a PKI-based end-to-end

For Huawei products, digital certificates apply to the following scenarios:

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. 6

Figure 3-1 Example of networking that uses digital certificates

Issue 02 (2019-08-30) Copyright © Huawei Technologies Co., Ltd. 7

4.1.1 PKI Architecture