CMPv2 and TLS Callhome in O-RAN Fronthaul
- Venkateshu
- 22 minutes ago
- 8 min read
Certificate Management Protocol version 2 (CMPv2) and Transport Layer Security (TLS) callhome procedures form the cornerstone of secure communications in O-RAN (Open Radio Access Network) architecture. These protocols enable automated certificate lifecycle management and secure device-to-device authentication between O-RU (Open Radio Unit), O-DU (Open Distributed Unit), SMO (Service Management and Orchestration), and CA/RA (Certificate Authority/Registration Authority) servers.
CMPv2 Protocol Architecture and Implementation
Protocol Fundamentals and Design Principles
Certificate Management Protocol version 2 (CMPv2), defined in RFC 4210, serves as the primary mechanism for automated certificate lifecycle management in O-RAN networks. The protocol operates on a client-server architecture where O-RAN Physical Network Functions (PNFs) such as O-RUs act as clients, interacting with Certificate Authorities or Registration Authorities to obtain, renew, and revoke X.509 certificates.
The protocol supports transport over HTTP/HTTPS, enabling O-RAN devices to communicate securely with certificate authorities using widely supported web-based mechanisms.
CMPv2 Message Flow and Operations
The CMPv2 certificate enrollment process follows a structured message exchange pattern that begins with device discovery and progresses through authentication, certificate issuance, and installation phases.
Initial Registration (IR) represents the first certificate request from an O-RAN device that has never obtained a certificate from the target CA. The device sends an Initial Registration Request containing a Certificate Request Message Format (CRMF) structure embedded within a CMP message. This request includes the subject distinguished name, requested key algorithm specifications, optional certificate extensions, and authentication proof using either shared secrets or existing authentication certificates.
Certificate Update Requests (KUR) handle certificate renewal scenarios where devices possess valid certificates approaching expiration. The KUR message includes the existing certificate for authentication purposes and may contain a new public key if key rotation is required. This automated renewal capability is essential for maintaining continuous operation of O-RAN networks without service interruptions.
Revocation Requests (RR) enable immediate certificate invalidation when devices are compromised or decommissioned. The revocation request includes authentication information and the specific reason for revocation, triggering updates to Certificate Revocation Lists (CRL) or Online Certificate Status Protocol (OCSP) databases.
Error Handling and Response Mechanisms
CMPv2 implements comprehensive error handling through structured PKIStatusInfo responses that include PKIStatus indicators (success, failure, pending), specific FailInfo codes explaining rejection reasons, and optional human-readable StatusString messages. This structured approach enables automated retry logic and proper escalation procedures when manual intervention becomes necessary.
TLS Callhome Procedures and NETCONF Integration
NETCONF Call Home Architecture
TLS callhome procedures in O-RAN networks reverse the traditional client-server connection model to accommodate Network Address Translation (NAT) environments and firewall restrictions commonly found in operator deployments. In the callhome scenario, the O-RU acting as the NETCONF server initiates the TCP connection to the O-DU or SMO acting as the NETCONF client.
The well-known TCP port 4335 is designated for NETCONF TLS callhome connections, enabling O-RUs to establish secure management channels even when direct inbound connectivity is restricted. This approach is particularly valuable for O-RUs deployed in edge locations or behind carrier-grade NAT implementations
NETCONF Session Establishment
Following successful TLS handshake completion, the NETCONF protocol layer begins operation with capability exchange through NETCONF Hello messages. The NETCONF session utilizes either the chunked framing mechanism (if both peers support :base:1.1 capability) or the traditional end-of-message marker approach for message delineation.
Certificate-to-username mapping procedures determine NETCONF authorization levels based on presented client certificates. The mapping algorithm examines certificate fingerprints, subject alternative names, and common names to derive appropriate NETCONF usernames and associated privilege levels. This mapping enables fine-grained access control aligned with operational requirements.
O-RAN PKI Certificate Hierarchy and Types for CMPv2/TLS Operations
Certificate Profiles and PKI Architecture
O-RAN TLS Entity Certificate Specifications
O-RAN TLS entity certificates must conform to specific profile requirements defined in ETSI TS 104 107, ensuring consistent security properties across vendor implementations. These certificates support validity periods of one year or less, aligning with CA-Browser Forum requirements limiting certificate lifetimes to 397 days for certificates issued after September 1, 2020.
The Subject Distinguished Name structure follows the format "C=<country>, O=<Organization Name>, CN=<distinguishing name>" with UTF-8 encoding support for international deployments. For server certificates, the format "cn=<hostname>, ou=<servers>, dc=<domain>, dc=<domain>" provides additional hierarchical organization.
Key Usage extensions play critical roles in defining certificate purposes. The digitalSignature key usage is mandatory for both TLS client and server certificates, enabling entity authentication. When using RSA with TLS 1.2, the keyEncipherment extension must be set, while Diffie-Hellman or Elliptic Curve Diffie-Hellman implementations require the keyAgreement extension.
Extended Key Usage specifications differentiate between certificate roles. TLS client certificates include id-kp-clientAuth while server certificates specify id-kp-serverAuth. Entities functioning in dual roles (both client and server) must include both object identifiers to support bidirectional authentication scenarios.
Subject Alternative Name Requirements
SubjectAltName extensions are mandatory and critical for TLS server certificates, requiring at least one Fully Qualified Domain Name (FQDN) entry. RFC 6066 compliance prohibits using only IP addresses in subjectAltName fields for server certificates. Multiple subjectAltName entries are permitted, supporting complex deployment scenarios with multiple network interfaces or service endpoints.
Certificate validation procedures follow RFC 6125 specifications for domain-based application service identity verification. Applications must identify services through names carried in the subject field (CN-ID) or subjectAltName entries including DNS-ID, SRV-ID, and URI-ID formats.
Certificate Revocation and Validation Mechanisms
CRL Distribution Points are mandatory extensions that specify HTTP URI or LDAP locations for certificate revocation list retrieval. The authorityInfoAccess extension provides CA issuer information through id-ad-caIssuers and OCSP responder locations through id-ad-ocsp object identifiers.
TLS Feature Extension support enables OCSP stapling requirements using status_request(5) values, preventing downgrade attacks and ensuring fresh revocation status information. The extension follows RFC 7633 specifications for must-staple certificate behavior.
Operational Workflows and Implementation Examples
O-RU Startup and Certificate Enrollment Sequence
The O-RU initialization process begins with power-on network discovery using DHCP options to identify O-RU controllers and certificate authority servers. The O-RU performs M-Plane transport layer resolution including DHCP, MAC, VLAN, and IP address configuration.
CA/RA server discovery occurs through DHCP option mechanisms or static configuration, enabling the O-RU to locate appropriate certificate enrollment endpoints. The discovery process must identify both the certificate authority and any intermediate registration authorities required for the specific deployment architecture.
The CMPv2 enrollment workflow proceeds through initial registration request generation, authentication credential presentation, and certificate response processing. Authentication methods include message authentication codes using pre-shared reference and secret values, or signature-based authentication using existing certificates from trusted authorities.
Certificate Installation and NETCONF Session Establishment
Following successful certificate enrollment, the O-RU installs the received TLS entity certificate and initiates the callhome procedure to establish NETCONF management sessions. The callhome process targets all discovered O-RU controllers with which active NETCONF sessions do not already exist.
TLS connection establishment follows the standard handshake sequence with mutual certificate presentation and validation. The O-RU presents its client certificate while validating the server certificate presented by the O-DU or SMO. Certificate path validation must succeed for both certificates to establish the secure session.
NETCONF capability discovery enables feature negotiation between the O-RU and management system. The capability exchange determines available YANG models, supported operations, and protocol versions that will govern subsequent management interactions.
CMPv2 + TLS Call Home diagram
Below is a clear walkthrough of each stage represented in the sequence diagram you ran: CMPv2 enrollment for the O‑RU, then TLS Call Home and NETCONF session to the O‑DU, plus later renewal and optional revocation.
1) Pre-conditions
O-RU knows the CMP server URL (for example, https://pki.example/cmp).
O-RU has bootstrap authentication to protect CMP messages:
Either a shared secret to produce MAC-protected messages, or
An “auth certificate” and private key to produce signature-protected messages.
O-RU either already generated its own key pair or will generate one before requesting a certificate.
O-DU already has its TLS server certificate provisioned (so it can authenticate itself during Call Home).
O-RU has the Call Home target info (O-DU host:port; often 4335 for NETCONF/TLS Call Home).
2) CMPv2 Initial Enrollment (IR/IP)
Goal: Get the O‑RU’s TLS client/entity certificate from the CA.
2.1 O-RU → CA: IR request (blue)
Sends PKIMessage [ir] containing one or more CRMF requests:
certReq with the certificate template (subject, SANs, extensions),
popo (Proof of Possession) proving O‑RU holds the private key,
optional regInfo for enrollment metadata.
The entire message is protected (MAC if shared secret; signature if using an auth cert).
2.2 CA → O-RU: IP response (violet)
CA validates the request (auth, PoP, policy).
Returns PKIMessage [ip] with CertRepMessage:
Typically “status=granted” and a CertifiedKeyPair with the issued certificate.
Optionally caPubs/extraCerts supplying intermediate CA certificates.
2.3 Optional pending/polling (orange)
If the CA previously indicated “pending/waiting,” the O‑RU polls:
O-RU sends PollReq; CA returns PollRep with checkAfter.
Repeat until CA is ready, then CA returns a normal IP with status=granted and the cert.
2.4 Confirmation (green)
O-RU → CA: CertConf to indicate acceptance of the issued certificate (status=ok).
CA → O-RU: PKIConf acknowledges the confirmation.
Result: O‑RU now holds its TLS client certificate, private key, and CA chain.
3) TLS Call Home (NETCONF over TLS)
Goal: Establish a secure management channel initiated by the O‑RU to the O‑DU.
3.1 O-RU initiates outbound connection (cyan)
O-RU opens TCP to O‑DU’s NETCONF/TLS Call Home port (commonly 4335).
This fits NAT/firewall constraints because the edge device (O‑RU) dials out.
3.2 Mutual TLS handshake (cyan)
O-RU sends TLS ClientHello.
O-DU responds with:
ServerHello,
Certificate (O‑DU’s TLS server certificate),
CertificateRequest (to require client authentication).
O-RU presents its new TLS client certificate (obtained via CMPv2).
Both sides exchange Finished messages to complete the handshake.
3.3 Certificate validation rules (note)
O-RU validates the O‑DU’s server certificate against trusted CA roots and ensures EKU contains serverAuth.
O-DU validates the O‑RU’s client certificate and ensures EKU contains clientAuth.
4) NETCONF session over TLS
Goal: Start management operations after transport is secure.
4.1 Hello exchange (lime)
O-RU sends NETCONF <hello> with its capabilities.
O-DU replies with NETCONF <hello> and its capabilities.
Now O‑DU can manage the O‑RU using YANG models over the encrypted, mutually authenticated channel.
5) CMPv2 Renewal (KUR/KUP)
Goal: Refresh O‑RU certificates before they expire, without service disruption.
5.1 O-RU → CA: KUR (blue)
O-RU requests a new certificate via PKIMessage [kur].
May keep the same key or roll over to a new key (PoP shows it controls the private key).
Protects the request with its existing (still-valid) certificate.
5.2 CA → O-RU: KUP (violet)
CA returns PKIMessage [kup] with status=granted and the newCertifiedKeyPair.
5.3 Confirmation (green)
O-RU sends CertConf (status=ok).
CA acknowledges with PKIConf.
O-RU updates its active cert/key and either continues the current session (if your stack supports rekey/renegotiate) or re-establishes Call Home as needed.
6) CMPv2 Revocation (RR/RP)
Goal: Invalidate O‑RU’s cert if the device is decommissioned or a key is compromised.
6.1 O-RU → CA: RR (red)
Sends PKIMessage [rr] with RevReqContent indicating certId, reasonCode, and optional CRL entry details.
6.2 CA → O-RU: RP (red)
Returns PKIMessage [rp] (RevRepContent) with status=granted.
Certificate will appear in CRLs/OCSP as revoked; subsequent TLS auth with that cert should fail
Certificate Renewal and Lifecycle Management
Automated certificate renewal occurs before certificate expiration through CMPv2 Certificate Update Requests (KUR). The renewal process uses the existing certificate for authentication while potentially rotating to new key pairs. This automation ensures continuous operation without manual intervention or service disruptions.
Certificate revocation procedures handle compromised or decommissioned devices through Revocation Requests that update CRL and OCSP databases. The revocation process must be rapid enough to prevent unauthorized access while maintaining operational continuity for legitimate devices.
Conclusion
CMPv2 and TLS callhome procedures represent sophisticated security mechanisms that enable automated certificate management and secure device authentication in O-RAN networks. The integration of these protocols provides the foundation for scalable, secure, and operationally efficient management of distributed radio access network components. Proper implementation requires careful attention to certificate profiles, authentication procedures, and operational workflows that align with both O-RAN specifications and broader telecommunications security standards. As O-RAN deployments continue to expand, these protocols will remain essential for maintaining security and operational integrity across diverse vendor ecosystems and deployment scenarios.
References
1. O-RAN Working Group 4 (Open Fronthaul Interfaces WG) - Management Plane Specification
2. RFC 4210 - Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
3. RFC 8071 - NETCONF Call Home and RESTCONF Call Home
Comments