PKI Certificate Storage and Retention

The CMP Converged Monetisation Platform. The MDS Global product that supports customer care and billing for digital service providers. Ansible installer uses the MDS Global PKI infrastructure to generate and manage the TLS certificates required by the CMP components.

PKI files are generated on the Ansible control server during the pre-deployment phase. The generated PKI material is subsequently used by the Ansible deployment to install certificates, private keys and truststores on the target CMP hosts.

PKI storage location

The PKI files are generated and stored in the specified PKI TLS Certificate Generation Path as entered into the inventory on the Ansible control server: <pki_tls_src_files>/mdsglobal/pki/<jdbc_server>/

The exact location is determined by the PKI configuration used by the deployment.

The directory contains the PKI material associated with the deployed CMP system, including:

• The Application Root CA certificate.
• The Application Root CA private key.
• Root CA metadata.
• Service certificates and private keys.
• Service certificate metadata.
• Generated Java A widely used object-oriented programming language that is designed for use in the distributed environment of the internet. It is the most popular programming language for Android smartphone applications truststores containing the appropriate trusted CA certificates.
• Other PKI files required by the deployment.

The PKI directory is part of the persistent deployment state and must not be treated as temporary deployment data.

Why the PKI files must be retained

The Application Root CA is used to issue the TLS certificates for the CMP services. Subsequent deployments and upgrades must continue to use the same Root CA and existing PKI state wherever the certificates remain valid.

The PKI files must therefore be retained on the Ansible control server after the initial deployment.

In particular, the Root CA private key must be retained securely. If it is lost and a new Root CA is generated, the new CA will have a different identity and certificates issued by the original CA will no longer be trusted by components configured to trust the new CA.

Retaining the PKI state also allows subsequent deployments to:

• Detect existing certificates.
• Determine whether certificates require regeneration.
• Preserve certificates that are still valid.
• Renew certificates when they approach expiry.
• Detect changes to certificate configuration such as SANs or certificate issuer.
• Rebuild or update truststores consistently.
• Maintain trust between CMP components during upgrades.

Requirements for upgrades and subsequent deployments

The same Ansible control server PKI directory should be made available to all subsequent deployments and upgrades of the CMP system.

Before performing an upgrade or redeployment, ensure that the PKI directory for the target system is present and accessible to the user A person with the capability to log in to the CMP GUI software, such as a customer service advisor or agent. running Ansible.

For example:

The exact files and directory structure may vary between CMP versions.

Backup and security

The PKI directory should be included in the organisation's normal backup strategy for the Ansible control server.

The Root CA private key and service private keys are sensitive security material and must be protected against unauthorised access.

Access to the PKI directory should therefore be restricted to the deployment user and authorised administrators. The private key files must not be copied to source control systems, shared repositories, or other locations where they could be accessed by unauthorised users.

When the Ansible control server is replaced or rebuilt, the existing PKI directory must be restored before performing subsequent CMP upgrades or deployments.

Do not delete or regenerate the existing Application Root CA simply to refresh or renew service certificates. Service certificate renewal and Root CA regeneration are separate operations. Root CA regeneration should only be performed as an intentional PKI lifecycle operation, as it can require all certificates and truststores issued from the previous CA to be replaced.

Multiple CMP system instances

Where multiple CMP system instances are deployed, each system maintains its own PKI state unless the deployment has been specifically configured to use shared PKI material.

The PKI directory associated with each system must therefore be retained and made available to the Ansible control server used for future deployments and upgrades of that system.

The PKI files are generated and consumed by the Ansible deployment process and do not need to be manually copied to the target CMP servers unless specifically required by the deployment procedure.