1 Introduction

Oracle Communications Certificate Management (OCCM) is an automated solution for managing the certificates needed for Oracle 5G Network Functions (NFs). OCCM constantly monitors and renews the certificates based on their validity or expiry period.As 3GPP recommends using separate certificates based on the client or server mode and the type of workflow, automated certificate management eliminates any possibilities of network disruption due to expired certificates. In SBA network deployments, the Network Functions (NFs) are required to support multiple operator certificates for different purposes and interfaces. This amounts to hundreds of certificates in the network with varying validity periods and unwieldy to monitor and renew the certificates manually. Hence, automation of certificate management becomes important to avoid network disruptions due to expired certificates.

This guide describes how to install or upgrade Oracle Communications Certificate Management (OCCM) in a cloud native environment. It also includes information on performing fault recovery for OCCM.

Note:

This guide covers the installation instructions when Podman is the container platform with Helm as the Packaging Manager. For any other container platform, the operator must use the commands based on their deployed container runtime environment.

1.1 Overview

OCCM integrates with the Certificate Authority(s) using Certificate Management Protocol Version 2 (CMPv2) and RFC4210 to facilitate these certificate management operations:

• Operator-initiated certificate creation
• Operator-initiated certificate recreation
• Automatic certificate monitoring and renewal

Figure 1-1 OCCM Integration with CA

OCCM supports transport of CMPv2 messages using HTTP-based protocol.

OCCM provides the following mechanisms to establish initial trust between OCCM and CA(s):

1. Certificate-based message signing
2. Pre-shared key or MAC based authentication

All the subsequent CMPv2 procedures are authenticated using the certificate-based mechanism in compliance with 3GPP TS 33.310.

The keys and X.509 certificates are managed using Kubernetes secrets.

1.2 OCCM Architecture

OCCM is a Cloud Native application consisting of a single microservice. The OCCM lifecycle is managed by a Helm chart and delivered as a CSAR package that includes the application container images and the Helm chart.

Figure 1-2 OCCM Architecture

Architecture Description

OCCM is deployed as a single Kubernetes Pod and has a small resource footprint. The OCCM application uses a set of OpenSSL Certificate Management Protocol (CMP) CLI commands based on the provided configuration and the certificate management procedure that needs to be carried out at a point in time. The Output – Key and Certificate – is stored in configuration defined Kubernetes secret.

Operator provides the desired key and certificate configuration through Console. OCCM contacts the CA for certificate signing. After successful Certificate creation, OCCM writes the key and certificate in Kubernetes secrets.

In the diagram above:

1. Operator provides the desired Key and Certificate configuration.
2. OCCM contacts the CA for certificate signing.
3. OCCM writes the key and certificate in Kubernetes Secrets. Starts monitoring of the secret for modification or deletion.

OCCM provides the following deployment models to support certificate management for the integrated NF(s) instantiated within the same cluster:

• Dedicated deployment model - OCCM resides in the same Kubernetes namespace as the NF or Components.
• Shared deployment model - OCCM is deployed in a separate Kubernetes namespace and can manage certificates of multiple NFs or components deployed in other Kubernetes namespaces.

Appropriate permissions must be assigned to OCCM using Kubernetes Service Account, Role and Role Binding, based on the selected deployment model.

OCCM provides secret monitoring capabilities, which help the operator to monitor and manage previously created certificates. OCCM identifies and takes necessary action if certificates are modified or deleted manually, without experiencing loss of service.

Certificate monitoring is useful in the following scenarios:

• The certificate or the Kubernetes secret holding the certificate is deleted.
• The certificate is manually updated.

For more information, see "Monitoring Secrets for Manual Update or Delete" in the Oracle Communications Cloud Native Configuration Console User Guide.

1.3 OCCM Deployment Models

The following deployment models are supported by OCCM:

• Dedicated deployment model - OCCM resides in the same Kubernetes namespace as the NF or components.
• Shared deployment model - OCCM is deployed in a separate Kubernetes namespace and can manage certificates of multiple NFs or components deployed in other Kubernetes namespaces.

Figure 1-3 Deployment Model-1: Dedicated OCCM Deployment – Single Namespace Management

In the dedicated OCCM deployment model, OCCM is deployed in the same namespace as the component(s) managed by it.

Figure 1-4 Deployment Model-2: Shared OCCM Deployment - Multiple Namespaces Management

In the shared deployment model, OCCM is deployed in a separate Kubernetes namespace and can manage certificates of multiple NFs or components deployed in other Kubernetes namespaces. OCCM provides Key and certificate for NFs running in multiple namespaces. OCCM needs privileges to be able to create or write Kubernetes secrets in multiple namespaces. Care must be taken to not provide Kubernetes Cluster Role access as it provides access to all namespaces in the cluster. Multiple namespace specific roles are created and then bind to OCCM service account using role binding. OCCM is deployed in a dedicated namespace different from the components’ namespace managed by it. For more information, see Creating Service Account, Role, and Rolebinding.

OCCM Configuration Maximum Limits

Following table describes the maximum limits defined in OCCM configuration:

Table 1-1 OCCM Configuration Maximum Limits

Configurations	Maximum Limit
Maximum Number of Certificate Configuration Supported	200
Maximum Number of Issuer Configuration Supported	30
Maximum Number of Unique Namespace Configuration Supported	30
Maximum Number of Bulk Certificate Migration Configuration Supported	15

1.4 Reference

Refer to the following documents for more information:

• Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide
• Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide
• Oracle Communications Cloud Native Core, Operations Services Overlay Installation and Upgrade Guide
• Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide
• Oracle Communications Cloud Native Core Automated Test Suite User Guide
• Oracle Communications Cloud Native Core, Network Function Data Collector User Guide
• Oracle Communications Network Analytics Data Director Installation Guide
• Oracle Communications Cloud Native Core Release Notes
• Oracle Communications Cloud Native Core Licensing Information User Guide
• Oracle Communications Cloud Native Core Solution Upgrade Guide
• Oracle Communications Cloud Native Core Security Guide
• Oracle Communications Cloud Native Core, Certificate Management Network Impact Report
• Oracle Communications Cloud Native Core, Certificate Management User Guide
• Oracle Communications Cloud Native Core, Certificate Management REST Specification Guide
• Oracle Communications Cloud Native Core, Certificate Management Troubleshooting Guide

1.5 Oracle Error Correction Policy

The table below outlines the key details for the current and past releases, their Generaly Available (GA) dates, and the end dates for the Error Correction Grace Period.

Table 1-2 Oracle Error Correction Policy

Cloud Native Core Release Number	General Availability (GA) Date	Error Correction Grace Period End Date
3.25.1.200.0	July 2025	July 2026
3.25.1.100.0	April 2025	April 2026
3.24.3	October 2024	October 2025
3.24.2	July 2024	July 2025

Note:

• For the latest patch releases, see their corresponding Oracle Communications Cloud Native Core Release Notes.
• For a release, Sev1 and Critical Patch Unit (CPU) patches are supported for 12 months. For more information, see Oracle Communications Cloud Native Core and Network Analytics Error Correction Policy.

1.6 Oracle Open Source Support Policies

Oracle Communications Cloud Native Core uses open source technology governed by the Oracle Open Source Support Policies. For more information, see Oracle Open Source Support Policies.