3 OCCM Supported Features

This section describes the features supported by Oracle Communications Cloud Native core, Certificate Management (OCCM).

3.1 Integration with Certificate Authority

OCCM integrates with one or more Certificate Authorities (CAs) using the Certificate Management Protocol version 2 (CMPv2), as proposed by the 3GPP TS33.310. Operators have the flexibility to configure OCCM to integrate with a single CA or multiple CAs, depending on the layout of CA hierarchy deployed in the network. However, it is recommended that each intermediate CA manage multiple certificates of the same type.

The two CMPv2 procedures used by OCCM are:
  • Initialization procedure: This is used to create certificates.
  • Key update procedure: This is used for certificate renewal scenarios.
OCCM employs two modes to establish initial trust between OCCM and CAs for initial trust establishment:
  • Using a pre-shared key
  • Using a key and certificate
These options are available when the first request is made towards the CA. For all subsequent requests, OCCM uses the certificate based mechanism to sign the CMPv2 requests in compliance with 3GPP standards.

Note:

OCCM supports HTTP 1.0 and HTTP 1.1 versions. OCCM initiates the request using HTTP 1.0. If the CA supports HTTP 1.1 only, then OCCM shifts to using HTTP 1.1 version. HTTPs is not supported in this release.

3.1.1 Establishing Initial Trust Between OCCM and CA

OCCM can be configured to establish trust between Oracle Communication Certificate (OCCM) and Certificate Authorities (CAs) by enabling PKI message protection in the following ways:
  • MAC based trust establishment
  • Certificate based trust establishment
3.1.1.1 MAC Based Trust Establishment

OCCM supports initial trust establishment with each of the configured CAs using the preconfigured pre-shared (MAC) key.

Figure 3-1 MAC Based Trust Establishment


MAC Based Trust Establishment

OCCM generates the key pair and requests for the OCCM certificate for each of the configured CAs using the first Initialization Request. The first Initialization Request towards each of the CAs is signed using the preshared key. The CA authenticates the initialization request and signs the OCCM Certificate. OCCM can be configured to authenticate the responses of the first initializing procedure using the preshared (MAC) key. All subsequent requests are always signed using the OCCM key and certificate.

3.1.1.2 Certificate Based Trust Establishment

OCCM supports initial trust establishment with CA using the preconfigured private key and x.509 certificate.

Figure 3-2 Certificate Based Trust Establishment


Certificate Based Trust Establishment

OCCM signs the first initialization request towards a CA using preconfigured key or certificate.

OCCM can be configured to:
  • Continue using the same key and certificate to sign the subsequent CMPv2 requests OR
  • Generate a new certificate using the first Initialization Request

In case OCCM uses the same key and certificate to sign the subsequent CMPv2 requests, OCCM requests for generation of the NF certificate in the first Initialization Request.

In case OCCM generates a new certificate using the first Initialization Request, OCCM requests for generation of OCCM certificate in the first Initialization Request. NF Certificate generation is requested from next Initialization Request onwards.

3.2 Managing Issuers

Issuers, also called Certificate Authorities (CAs), are a trusted entity that issues Secure Sockets Layer (SSL) certificates. OCCM supports the following aspects of issuer management:
  • Pre-configuration for OCCM Bootstrapping
  • Creating Issuers
  • Updating Issuers
  • Deleting Issuers

3.2.1 Pre-configuration for OCCM Bootstrapping

The following secrets can be pre-configured for OCCM bootstrapping:
  • MAC Secret: The MAC secret is a manually configured pre-shared key or password based MAC secret and reference. This is used by OCCM to sign the first initialization request. CA then validates the request and issues a signed OCCM certificate. For more information see the 'Using the pre-shared key' section in OCCM Certificate Configuration Modes.
    To create the MAC Secret, run the following command:
    kubectl create secret generic <k8s secret name> --from-literal=<mac secret key>=<mac secret value> --from-literal=<reference key>=<reference value> -n <namespace>
    For example:
    kubectl create secret generic ca1-mac-secret --from-literal=pwd='pass:****' --from-literal=ref='abcd' -n ns1
  • CMP Identity Secret: The CMP Identity secret is a manually configured private key and certificate, using which OCCM certificate is requested from CA. This is used by OCCM to sign the first initialization request. CA then validates the request and issues a signed OCCM certificate. You can also use the same private key and certificate as OCCM certificate. For more information, see the 'Using the pre-configured private key and certificate' section in OCCM Certificate Configuration Modes
    To create the CMP Identity Key, run the following command:
    kubectl create secret generic <k8s secret name> --from-file=<cmp key file location> --from-file=<cmp cert file location> -n <namespace>
    For example:
    kubectl create secret generic ca1-cmp-identity-secret --from-file=cmpkey.pem --from-file=cmpcert.pem -n ns1
  • OCCM Trust Store Secret: The OCCM Trust Store secret holds OCCM trust store information (CA certificates), and is used as a trust anchor when validating the digital signature included in the CMP responses.
    To create the OCCM Trust Store secret, run the following command:
    kubectl create secret generic <k8s secret name> --from-file=<CA root cert file location> --from-file=<Intermediate CA cert file location> --from-file=<CMP server cert file location> -n <namespace>
    For example:
    kubectl create secret generic ca1-occm-trust-store-secret --from-file=caroot.pem --from-file=intcacert.pem --from-file=servercert.pem -n ns1

3.2.2 Creating Issuer

Issuers are resources that represent CAs and are able to generate signed certificates. You can configure issuers through REST API or using the CNC Console GUI. The maximum number of issuers that can be supported at a time is 30.

Configuring Issuer Using CNC Console GUI

To manually configure issuer using CNC Console GUI:
  1. Log in to CNC Console using your log in credentials and select the OCCM Instance.
  2. Click OCCM from the left pane and then click Issuer.
  3. Click Add. The Create Issuer page appears.

    Figure 3-3 Create Issuer


    Create Issuer

  4. Enter the following information on the Create Issuer page :

    Table 3-1 Create Issuer

    Field Name Description
    Name Name of the Issuer
    Recipient Distinguished Name

    Distinguished name(DN) of the CMP server(usually the addressed CA). Used in the recipient field of CMP request message headers.

    The argument must be formatted as /type0=value0/type1=value1/type2=....

    Special characters may be escaped by \ (backslash); whitespace is retained. Empty values are permitted, but the corresponding type will not be included. Giving a single / will lead to an empty sequence of RDNs (a NULL-DN). Multi-valued RDNs can be formed by placing a + character instead of a / between the AttributeValueAssertions (AVAs) that specify the members of the set. Example:

    /DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe
    Issuer Distinguished Name

    X509 issuer Distinguished Name of the CA server to place in the requested certificate template in IR/KUR.

    The argument must be formatted as /type0=value0/type1=value1/type2=....

    Special characters may be escaped by \ (backslash); whitespace is retained. Empty values are permitted, but the corresponding type will not be included. Giving a single / will lead to an empty sequence of RDNs (a NULL-DN). Multi-valued RDNs can be formed by placing a + character instead of a / between the AttributeValueAssertions (AVAs) that specify the members of the set. Example:

    /DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe
    Total Timeout (Seconds) The total time in seconds allowed for the CMP transaction to complete
    Message Timeout (Seconds) The total time (in seconds) a CMP request-response message round trip is allowed to take.
  5. Under CMP Client Authentication Options For OCCM certificate, enter the following information:

    Table 3-2 Initial Authentication Options

    Field Name Possible Values
    Type MAC, SIGNATURE

    For more information, see OCCM Certificate Configuration Modes.

    Digest Algorithm SHA256, SHA384, SHA512
    MAC Algorithm HMACSHA256, HMACSHA384, HMACSHA512

    Figure 3-4 CMP Client Authentication Options For OCCM Certificate


    CMP Client Authentication Options For OCCM Certificate

  6. If you are using the password based MAC authentication mechanism, then under MAC Authentication Input, enter the following information:

    Table 3-3 MAC Authentication Input

    Field Name Description
    Namespace Name of the Kubernetes namespace
    Secret Name Kubernetes secret name
    Password Key Kubernetes secret data key against which MAC secret is provided.
    Reference Key Kubernetes secret data key against which reference string is provided.

    Figure 3-5 MAC Authentication Input


    MAC Authentication Input

  7. Under Signature Authentication Input, enter the following information:

    Table 3-4 Signature Authentication Input

    Field Name Description
    Namespace Name of the Kubernetes namespace
    Secret Name A unique secret name
    Key Kubernetes secret data key against which the pre-configured private key file (private key file for the client's current CMP signer certificate) is provided.
    Cert Kubernetes secret data key against which the pre-configured certificate (client's current CMP signer certificate) is provided.
    Extra Certs Extra Certificates, if any, for client authentication.

    Figure 3-6 Signature Authentication Input


    Signature Authentication Input

  8. Under CMP Client Authentication Options For Other certificate, enter the following information:

    Table 3-5 CMP Client Authentication Options For Other certificate

    Field Name Possible Values
    Type SIGNATURE
    Digest Algorithm SHA256, SHA384, SHA512

    Figure 3-7 CMP Client Authentication Options For Other certificate


    CMP Client Authentication Options For Other certificate

  9. Under Signature Authentication Input, enter the following information:

    Table 3-6 Signature Authentication Input

    Field Name Description
    Namespace Name of the Kubernetes namespace
    Secret Name A unique secret name
    Key Kubernetes secret data key against which OCCM key is provided or created based on whether OCCM certificate is created in manual or automatic mode.
    Cert Kubernetes secret data key against which OCCM certificate is provided or created based on whether OCCM cert is created in manual or automatic mode.
    Extra Certs List of Kubernetes secret data keys against which the certificates to append in the extraCerts field can be provided or will be created (if received from CA) along with the OCCM certificate, based on whether OCCM cert is created in manual or automatic mode.

    Figure 3-8 Signature Authentication Input


    Signature Authentication Input

  10. Under Occm Trust-Store Secret Input, enter the following information:

    Table 3-7 Occm Trust-Store Secret Input

    Field Description
    Namespace Name of the Kubernetes namepace
    Name Kubernetes secret which holds OCCM trust store information (CA certificates).
    Root CA Certs The certificate(s), typically of root CAs, the client shall use as trust anchors when validating the certificate issued by CA.

    Note: If server cert is present this is ignored.

    Intermediate CA Certs Any untrusted intermediate CA certificate(s) to use when validating newly enrolled certificates.
    Server Cert CMP server or CA server's certificate to expect and directly trust when validating the certificate issued by CA.

    Note: If this is present root CA certificates will be ignored.

    Figure 3-9 Occm Trust-Store Secret Input


    Occm Trust-Store Secret Input

  11. Enter either the root CA certificates and intermediate CA certificate, or the server certificate in the respective fields.
  12. Click Save.

3.2.3 Updating Issuer

You can update the issuer as long as it is not in use by any certificate. To update the issuer:
  1. Log in to CNC Console using your log in credentials and select the OCCM Instance.
  2. Click OCCM from the left pane and then click Issuer.

    Figure 3-10 Issuer Page


    Issuer Page

  3. Click the pencil icon next to the issuer that you want to update. The Edit Issuer page appears.

    Figure 3-11 Edit Issuer


    Edit Issuer

  4. Edit the fields that you need to update and then click Save

Note:

Issuer can't be edited if it is in use by any certificate.

3.2.4 Deleting Issuers

To delete issuers:
  1. Log in to CNC Console using the log in credentials, and select the OCCM Instance.
  2. Click OCCM from the left pane and then click Issuer.
  3. Click Delete and click OK on the confirmation prompt to delete the issuer.

Note:

An issuer can only be deleted if there are no certificates referring to this issuer entry.

3.3 Managing Certificates

OCCM creates a new key-pair (private and public key) for each of the certificates to be created. This is applicable to both NF and OCCM certificates.

OCCM supports the following key aspects of certificate management:
  • Creating OCCM Certificates
  • Creating NF Certificates
  • Monitoring and Renewing OCCM and NF Certificates

Note:

  • Grafana dashboards can be used to visualize certificate status such as expiry time, etc.
  • The maximum number of certificates supported (OCCM certificates and NF certificates combined) is 100.

3.3.1 Creating OCCM Certificates

Each certificate configuration in OCCM is a certificate request. It specifies input fields that are used to generate a private key pair and certificate signing request to obtain a signed certificate from the referenced issuer.

To create an OCCM certificate:
  • A CMPv2 Initialization Request is sent to the CA. Each request supports one certificate request. A separate initialization request for each certificate request is used.
  • The Initialization Requests and Certificate Confirms are digitally signed by the CMP Identity Key.
  • OCCM supports Proof of Possession (PoP) in the initialization request. PoP of the signing key contains the algorithm identifier and signature. This signature is based on the certificates template structure.
  • The recommended signing algorithms for the CMPv2 messages and Proof of Possession are RSA Encryption and ECDSA.
  • The recommended hash algorithms for the CMPv2 messages and Proof of Possession are SHA-256 and SHA-384.

When the preshared key mechanism is used to establish the initial trust between OCCM and CA, the first OCCM certificate, also known as CMP Identity Key Certificate, corresponding to a particular CA is created in the first initialization procedure.

When certificate based initial trust is established, then the operator can choose to continue with the preconfigured OCCM certificate or can choose to create a new OCCM certificate via the first initialization procedure, which is configurable.

To create OCCM Certificates:
  1. Log in to CNC Console using your log in credentials and select the OCCM Instance.
  2. Click OCCM from the left pane and then click Certificate.
  3. Click Add. The Create Certificate page appears.

    Figure 3-12 Create OCCM Certificate


    Create OCCM Certificate

  4. Enter the following information:

    Table 3-8 Create OCCM Certificate

    Field Name Description and Possible Values
    Name Name of the certificate
    Cert Type Select OCCM for OCCM certificates
    Network Function OCCM
    Purpose Purpose of the OCCM Certificate
    Issuer Name of the issuer for the certificate
    Life Cycle Management Possible values are MANUAL and AUTOMATIC. For more information, see OCCM Certificate Configuration Modes.
  5. Under Private Key Options, enter the following information:

    Table 3-9 Private Key Options

    Field Name Possible Values
    Key Algorithm RSA, EC
    Key Encoding DER, PEM
    Key Size KEYSIZE_2048, KEYSIZE_4096
    Elliptic Curve SECP256k1, SECP384r1

    Figure 3-13 Private Key Options


    Private Key Options

  6. The Private Key Output section is auto populated from corresponding issuer after the certificate is saved. You can skip this section.

    Table 3-10 Private Key Output

    Field Name Description
    Namespace Name of the namespace
    Secret Name Kubernetes Secret Name
    Key Kubernetes secret key against which the key-pair will be stored.

    Figure 3-14 Private Key Output


    Private Key Output

  7. Under Public Key Certificate Options, enter the following:

    Table 3-11 Public Key Certificate Options

    Field Name Description
    Key Usage Value(s): DIGITAL_SIGNATURE
    Extended Key Usage Value(s): CLIENT_AUTH and SERVER_AUTH
    Basic Constraints Value(s): END_ENTITY
    Subject Country: Enter country code:

    State: Enter state code

    Location: City or town where company is legally located.

    Organization: Name of your organization

    Organisation Unit: Name of business unit

    Common Name: The Common Name (CN) represents the server name to be protected by the certificate.

    Requested Validity (Days): Number of days requested for which the certificate will be valid.

    Figure 3-15 Public Key Certificate Options


    Public Key Certificate Options

  8. Under Subject Alternate Names, enter the following:

    Table 3-12 Subject Alternate Names

    Field Name Description
    IP Address The IPs you want to protect under this certificate
    DNS Names List of DNS domain names
    URI ID API Roots List of URI ID
    URI ID URNs List of URI ID

    Figure 3-16 Subject Alternate Names


    Subject Alternate Names

  9. The Certificate Output section is auto populated from corresponding issuer after the certificate is saved. You can skip this section.

    Table 3-13 Certificate Output

    Field Name Description
    Namespace Name of the namespace
    Secret Name Name of the secret
    Key The key against which the certificate will be populated

    Figure 3-17 Certificate Output


    Certificate Output

  10. (Optional) Under Certificate Chain Output, enter the following:

    Table 3-14 Certificate Chain Output

    Field Name Description
    Namespace Name of the namespace
    Secret Name Name of the secret
    Key Kubernetes secret key against which the certificate chain will be stored.

    Figure 3-18 Certificate Chain Output


    Certificate Chain Output

    If the Certificate Chain Output section is filled, then the certificate chain can either be obtained from the CA or can be configured manually. This is based on the extractCertChainFromCmpResponse helm parameter. For more information, see Oracle Communications Cloud Native Core, Certificate Management Installation, Upgrade, and Fault Recovery Guide

    Note:

    extractCertChainFromCmpResponse: This field when set true specifies that certificate chain will be extracted from CA's CMP response message. When false, the operator can configure the chain manually. This certificate chain is used in the TLS handshake along with the certificate.
  11. Click Save.

3.3.1.1 OCCM Certificate Configuration Modes

The following section highlights the configuration applicable to these modes and control how the OCCM certificates are generated. The purpose of the following issuer configuration and certificate configuration sections is to highlight the difference in the fields for different modes.

OCCM can be configured with one of the following modes available to establish the initial Trust with the CA(s):
  • Using the pre-shared key
  • Using the pre-configured private key and certificate

Using the Pre-shared Key

With this mode of configuration, OCCM signs the first initialization request using the pre-shared key. CA validates the request and issues a signed OCCM certificate.

  1. Issuer configuration
    To configure the issuer using the pre-shared key,
    1. The MAC authentication input must be provided under CMP Client Authentication Options for OCCM Certificate.

      Figure 3-19 CMP Client Authentication Options for OCCM Certificate


      CMP Client Authentication Options for OCCM Certificate

    2. OCCM key and certificate output location must be specified under CMP Client Authentication Options for Other Certificate. OCCM certificate received from CA will be written here.

      Figure 3-20 CMP Client Authentication Options for Other Certificate


      CMP Client Authentication Options for Other Certificate

  2. Certificate configuration
    To configure the OCCM Certificate using the pre-shared key, select OCCM from the Cert Type drop down, and select AUTOMATIC from the Life Cycle Management on the Create Certificate page.

    Figure 3-21 OCCM Certificate Configuration using Pre-shared Key


    OCCM Certificate Configuration using Pre-shared Key

Using the pre-configured private key and certificate

The pre-configured private key and certificate mode can be used in the following two ways:
  1. OCCM signs the first initialization request using the pre-configured private key and certificate. CA validates the request and issues a signed OCCM certificate.
    1. Issuer Configuration
      Here, to configure the issuer,
      1. Provide the Signature authentication input under CMP Client Authentication Options for OCCM Certificate.

        Figure 3-22 CMP Client Authentication Options for OCCM Certificate


        CMP Client Authentication Options for OCCM Certificate

      2. OCCM key and certificate output location needs to be specified under CMP Client Authentication Options for Other Certificate. OCCM certificate received from CA will be written here.

        Figure 3-23 CMP Client Authentication Options for Other Certificate


        CMP Client Authentication Options for Other Certificate

    2. OCCM Certificate Configuration

      To configure the OCCM Certificate, select OCCM from the Cert Type drop down, and select AUTOMATIC from the Life Cycle Management on the Create Certificate page.

  2. The pre-configured private key and certificate (generated out of band) can itself be used as the OCCM certificate.
    1. Issuer Configuration
      1. Here, you must skip the CMP Client Authentication Options for OCCM Certificate.

        Figure 3-24 Issuer Configuration


        Issuer Configuration

      2. OCCM key and certificate output location needs to be specified under CMP Client Authentication Options for Other Certificate. Manually created OCCM key and certificate location should be specified here.

        Figure 3-25 CMP Client Authentication Options for Other Certificate


        CMP Client Authentication Options for Other Certificate

    2. OCCM Certificate Configuration
      To configure the OCCM Certificate, select OCCM from the Cert Type drop down, and select MANUAL from the Life Cycle Management on the Create Certificate page.

      Figure 3-26 OCCM Certificate Configuration


      OCCM Certificate Configuration

Note:

This configuration is available for each of the issuers, therefore the modes for the CAs can be controlled individually.

3.3.2 Create NF Certificates

To create an NF certificate:
  • A CMPv2 Initialization Request is sent to the CA. Each request supports one certificate request. A separate initialization request for each certificate request is used.
  • The Initialization Requests and Certificate Confirms are digitally signed by the CMP Identity Key.
  • OCCM supports Proof of Possession (PoP) in the initialization request. PoP of the signing key contains the algorithm identifier and signature. This signature is based on the certificates template structure.
  • The recommended signing algorithms for the CMPv2 messages and Proof of Possession are RSA Encryption and ECDSA.
  • The recommended hash algorithms for the CMPv2 messages and Proof of Possession are SHA-256 and SHA-384.

You can configure NF certificates through REST API or using the CNC Console GUI.

To create NF Certificates using CNC Console GUI:
  1. Log in to CNC Console using your log in credentials and select the OCCM Instance.
  2. Click OCCM from the left pane and then click Certificate.
  3. Click Add. The Create Certificate page appears.

    Figure 3-27 Create NF Certificate


    Create NF Certificate

  4. Enter the following information:

    Table 3-15 Create NF Certificate

    Field Name Description and Possible Values
    Name Name of the certificate
    Cert Type Select OTHER for NF certificates
    Network Function Name of the NF
    Purpose Purpose of the NF Certificate
    Issuer Name of the issuer for the certificate
    Life Cycle Management Possible values are MANUAL and AUTOMATIC.
  5. Under Private Key Options, enter the following information:

    Table 3-16 Private Key Options

    Field Name Possible Values
    Key Algorithm RSA, EC
    Key Encoding DER, PEM
    Key Size KEYSIZE_2048, KEYSIZE_4096
    Elliptic Curve SECP256k1, SECP384r1

    Figure 3-28 Private Key Options


    Private Key Options

  6. Under Private Key Output, enter the following information:

    Table 3-17 Private Key Output

    Field Name Description
    Namespace Name of the namespace
    Secret Name Kubernetes Secret Name
    Key Kubernetes secret key against which the key-pair will be stored.

    Figure 3-29 Private Key Output


    Private Key Output

  7. Under Public Key Certificate Options, enter the following:

    Table 3-18 Public Key Certificate Options

    Field Name Description
    Key Usage Value(s): DIGITAL_SIGNATURE
    Extended Key Usage Value(s): CLIENT_AUTH and SERVER_AUTH
    Basic Constraints Value(s): END_ENTITY
    Subject Country: Enter country code:

    State: Enter state code

    Location: City or town where company is legally located.

    Organization: Name of your organization

    Organisation Unit: Name of business unit

    Common Name: The Common Name (CN) represents the server name to be protected by the certificate.

    Requested Validity (Days): Number of days requested for which the certificate will be valid.

    Figure 3-30 Public Key Certificate Options


    Public Key Certificate Options

  8. Under Subject Alternate Names, enter the following:

    Table 3-19 Subject Alternate Names

    Field Name Description
    IP Address The IPs you want to protect under this certificate
    DNS Names List of DNS domain names
    URI ID API Roots List of URI ID (API root of the NF Instance)
    URI ID URNs List of URI ID (URN of the NFInstanceId)

    Figure 3-31 Subject Alternate Names


    Subject Alternate Names

  9. Under Certificate Output, enter the following for the NF certificate:

    Table 3-20 Certificate Output

    Field Name Description
    Namespace Name of the namespace
    Secret Name Name of the secret
    Key The key against which the certificate will be populated

    Figure 3-32 Certificate Output


    Certificate Output

  10. (Optional) Under Certificate Chain Output, enter the following:

    Table 3-21 Certificate Chain Output

    Field Name Description
    Namespace Name of the namespace
    Secret Name Name of the secret
    Key Kubernetes secret key against which the certificate chain will be stored.

    Figure 3-33 Certificate Chain Output


    Certificate Chain Output

    If the Certificate Chain Output section is filled, then the certificate chain can either be obtained from the CA or can be configured manually. This is based on the extractCertChainFromCmpResponse helm parameter. For more information, see Oracle Communications Cloud Native Core, Certificate Management Installation, Upgrade, and Fault Recovery Guide

    Note:

    extractCertChainFromCmpResponse: This field when set true specifies that certificate chain will be extracted from CA's CMP response message. When false, the operator can configure the chain manually. This certificate chain is used in the TLS handshake along with the certificate.
  11. (Optional) under CA Bundle Input, enter the following information:

    Table 3-22 CA Bundle Input

    Field Name Description
    Namespace Name of the namespace
    Secret Name Name of the secret
    Key Kubernetes secret key against which CA bundle certificate(s) will be stored.

    Figure 3-34 CA Bundle Input


    CA Bundle Input

  12. Click Save.

For sample NF configuration, see Creating NF Certificate Using OCCM - Sample Configuration.

3.3.3 Renew NF Certificates

To renew NF certificates:
  • OCCM sends CMPv2 Key Update Request (KUR) to the CA.
  • Key Update Request is used to renew OCCM certificate (CMP Identity Key) and NF Certificates.
  • The Key Update Request can be signed either by the OCCM key and certificate or by the certificate that is being renewed and its corresponding key. The corresponding certificate is included in extraCerts.
To renew certificates:
  1. Set the Key Update Request mode:
    Certificate renewal is a CMP Key Update Request (KUR) procedure. You can configure OCCM to sign the KUR in two ways:
    • Using OCCM key and certificate
    • Using the certificate that is being renewed and its corresponding key.
    You can use the occmConfig.cmp.config.useKurOldCertMode parameter to determine how OCCM will sign the KUR at the time of deployment.
    • If occmConfig.cmp.config.useKurOldCertMode is set to true, OCCM key and certificate will be used to sign the CMP KUR message.
    • If occmConfig.cmp.config.useKurOldCertMode is set to false, the certificate that is being renewed will be used.
    By default, this parameter is set to false.
  2. Configure Renew Before Expiration (days):

    OCCM monitors the certificate validity and initiates automatic certificate renewal based on the renew before period configuration. You can update the Renew Before Expiration (Days) field on the Create Certificate page at the time of certificate creation. This field specifies the number of days before the certificate expiry date when the certificate must be renewed.

    Figure 3-35 Renew Before Expiration (Days)


    Renew Before Expiration (Days)

3.3.4 Polling for Certificates

After the Initialization Response or Key Update Response, if the certificate is not available yet, the CA responds with PKI status 'Waiting'. The application keeps polling until the CA is ready with the certificate. Openssl implicitly handles polling. No additional configuration is required at the application level in this regard. However, the Total Timeout field can be set in the issuer configuration, which can restrict this polling time. It is the maximum total number of seconds a transaction may take, including polling etc. If the time specified by total timeout has elapsed, the polling will stop.

Figure 3-36 Polling for Certificates


Polling for Certificates

3.3.5 Deleting the Certificate Configuration

To delete the certificate configuration:
  1. Log in to CNC Console using your log in credentials and select the OCCM Instance.
  2. Click OCCM from the left pane and then click Certificate.
  3. Click Delete and click OK on the confirmation prompt to delete the certificate.

Note:

This procedure only deletes the certificate configuration from OCCM.
Run the following command to delete the Kubernetes secret holding the certificates:
kubectl delete secrets <secret name> -n <namespace>
For example:
kubectl delete secrets nrf-tls-secret -n ns1

3.4 OCCM Retry on Failure

OCCM supports retry on encountering failures during the certificate creation, certificate renewal and manipulation of Kubernetes secrets.

  • The procedure is retried until successful or interrupted by an action executed by the operator.
  • Retry is not controlled through any maximum limit.
  • The retry interval is an pre-defined value and set to 30s.

Some of the failure scenarios for which retries will be attempted:

  • CA is unavailable, not reachable, or busy
  • Any errors returned by CA
OCCM also provides a retry mechanism for errors encountered during Kubernetes secret update with the generated key and certificate. Based on the error encountered (insufficient permissions, Kubernetes internal errors etc), once the User fixes the issue, the Kubernetes secrets are automatically updated due to the ongoing retries.

Note:

In this case, there is no attempt to recreate the Key and Certificate. The retry is restricted to updating the Kubernetes secrets with the key and certificate that are already generated.

3.5 Network Policies

Network Policies are an application-centric construct that allows you to specify how a pod communicates with various network entities. It creates pod-level rules to control communication between the cluster pods and services, and to determine which pods and services can access one another inside a cluster.

Previously, the pods under deployment could be contacted by any other pods in the Kubernetes cluster without any restrictions. Now, Network Policy provides namespace-level isolation, which allows secured communications to and from OCCM with rules defined in the respective Network Policies. The network policies enforce access restrictions for all the applicable data flows except communication from Kubernetes node to pod for invoking container probe. For example, OCCM internal microservices can't be contacted directly by any other pods.

Managing Support for Network Policies

Enable

To use this feature, network policies need to be applied to the namespace wherein OCCM is applied.

Configure

You can configure this feature using Helm. For information about Configuring Network Policy for OCCM deployment, see Oracle Communications Certificate Management Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no specific metrics and alerts required for the Support of Network Policy functionality.