Certificate Management

Learn about certificates in Oracle Communications Unified Assurance and how to manage them.

Unified Assurance leverages SSL certificates for security, trust, and authentication in parts of the product. It includes a root CA bundle and a certificate generation tool in order to secure connections between internal components. You can optionally use a prepackaged CSR if you want to use an externally signed web certificate.

Certificates and corresponding keys are located in the following directory:

$A1BASEDIR/etc/ssl

Note:

You run most of the commands in this document as the root user. Before running the commands, set environment variables by running the following command:

source <UA_home>/.bashrc

where <UA_home> is the directory where you installed Unified Assurance, typically /opt/assure1.

Checking for Expired Certificates

Expired or untrusted Web certificates will display a warning to users of the web UI. Applications that rely on certificates, such as Docker and SVN, may stop functioning when certificates expire.

Host and User certificates expire after five years, and you must regenerate them when they expire. Because each server has its own Host certificate, certificates may expire at different times, depending on when the server was initially installed. If you want consistent expiration dates, you can regenerate all Host certificates on the same day, even those that have not yet expired, one server at a time.

Web certificates issued as of March 15, 2026 expire every 6.5 months (199 days). Thirteen month certificates issued before that date will continue to work on all major browsers up until their expiry date.

You can see when certificates have expired or will expire soon in the following places:

A message that appears on the login page if at least one certificate is expired or near expiry.

By running the following commands:

cat $A1BASEDIR/etc/ssl/Assure1CA.crt | openssl x509 -noout -dates
cat $A1BASEDIR/etc/ssl/BundleCA.crt  | openssl x509 -noout -dates  
cat $A1BASEDIR/etc/ssl/Host.crt | openssl x509 -noout -dates
cat $A1BASEDIR/etc/ssl/SiteCA.crt | openssl x509 -noout -dates
cat $A1BASEDIR/etc/ssl/User-api.crt | openssl x509 -noout -dates
cat $A1BASEDIR/etc/ssl/User-assure1.crt | openssl x509 -noout -dates
cat $A1BASEDIR/etc/ssl/User-kibana.crt | openssl x509 -noout -dates
cat $A1BASEDIR/etc/ssl/User-repl.crt | openssl x509 -noout -dates
cat $A1BASEDIR/etc/ssl/User-root.crt | openssl x509 -noout -dates
cat $A1BASEDIR/etc/ssl/Web.crt | openssl x509 -noout -dates

Renewing Unified Assurance Generated Certificates

To renew certificates:

On each server, set environment variables and regenerate the Host certificate by running the following commands:
```
export $HOSTFQDN=<host>
$A1BASEDIR/bin/CreateSSLCertificate --Type Host --CN $HOSTFQDN --Force
```
where:
- <UA_home> is the directory where you installed Unified Assurance, typically /opt/assure1.
- <host> is the appropriate server FQDN, for example hostname.example.com.
If your Web certificate is not signed by an external third-party, on presentation servers, regenerate the Web certificate by running one of the following sets of commands:
- For non-redundant environments:
```
export $WEBFQDN=<web_host>
$A1BASEDIR/bin/CreateSSLCertificate --Type Web --CN $WEBFQDN --Force
```
- For redundant environments:
```
export $WEBFQDN=<web_host>
export $HOSTFQDN1=<primary_host>
export $HOSTFQDN2=<secondary_host>
$A1BASEDIR/bin/CreateSSLCertificate --Type Web --CN $WEBFQDN --AltCN $HOSTFQDN1 --AltCN $HOSTFQDN2 --Force
```
where:
- <UA_home> is the directory where you installed Unified Assurance, typically /opt/assure1.
- <web_host> is the FQDN of the load balancer or shared FQDN for the presentation server that users visit to access Unified Assurance. For example, presentation.example.com.
- <primary_host> is the host FQDN of the primary presentation server. For example, hostname1.example.com.
- <secondary_host> is the host FQDN of the secondary presentation server. For example, hostname2.example.com.
If you do not know the values for <primary_host> or <secondary_host>, you can find them in the Servers UI, or by running the following commands on the primary presentation server:
```
a1mysql
select ServerHostFQDN, WebFQDN, ServerID, PrimaryServerID from Servers where IsPresentation=1;
select ServerHostFQDN, WebFQDN, ServerID, PrimaryServerID from Servers where PrimaryServerID in (select ServerID from Servers where IsPresentation=1);
```
If you regenerated the Web certificate, restart the web server by running the following command:
```
service assure1-web restart
```
On each server, reload the Broker to update the new certificate expirations by running the following command as the assure1 user:
```
$A1BASEDIR/bin/BrokerControl --batch reload
```

Rotating RKE2 Certificates

By default, RKE2 certificates expire after 12 months. To rotate certificates that have expired or will expire in 90 days or fewer, restart the RKE2 Server service using the Services UI.

Using an Externally Signed Web Certificate

By default, Web certificates are automatically signed by the Unified Assurance Global CA. This CA is not known to major web browsers and will display a warning to users. Without the CA being trusted, users must either allow an exception to the certificate or import the Unified Assurance Global CA. Most organizations will instead prefer users have a seamless experience by signing the Web certificate with a trusted vendor known by default to all major web browsers.

To set up an externally-signed Web certificate:

Gather the certificate request from the primary presentation server:
```
$A1BASEDIR/etc/ssl/Web.csr
```
Send the certificate request to the external authority for signing.
Copy the signed certificate sent back by the external authority to $A1BASEDIR/etc/ssl/Web.crt, overwriting the existing file.
(Optional) If the certificate request and key were not generated from Unified Assurance (for example, using a wildcard certificate for your domain), you will need to update the associated key. Copy the key file sent back by the external authority to $A1BASEDIR/etc/ssl/Web.key, overwriting the existing file.
Identify the intermediate chain file and add the contents to both the signed certificate file and the bundle CA certificates file:
```
cat intermediate.pem >> $A1BASEDIR/etc/ssl/Web.crt
cat intermediate.pem >> $A1BASEDIR/etc/ssl/BundleCA.crt
```
Copy the updated BundleCA.crt to every existing Unified Assurance server. New Unified Assurance servers will automatically get the new BundleCA.crt when they join.
Update the Podman trusted CA file on every existing server with the Presentation.Internal or any Cluster roles. New Unified Assurance servers will automatically use the correct CA file during installation.
```
cp $A1BASEDIR/etc/ssl/BundleCA.crt /etc/containers/certs.d/*/ca.crt
```
Note:

The command may fail if there is more than one directory in /etc/containers/certs.d. To resolve this, replace the ca.crt in the directory of the hostname used by the Podman system.
On all OpenSearch servers (those with the Database.Historical role), update the BundleCA.crt for OpenSearch:
```
cp $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/vendor/opensearch/config/certs/BundleCA.crt
```
Restart Telegraf, OpenSearch, and OpenSearch Dashboards.
Restart Apache to start using the new certificate:
```
systemctl restart assure1-web
```
Verify that the new certificate works.
Disable the login banner that prompts users to install the Unified Assurance global certificate:
1. In the UI, from the main navigation menu, select Configuration, and then Global Properties.
2. Select CertificateAuthorityWarning.
3. In the form, change Property Value to 0, then click Submit.

Troubleshooting Existing Certificates

The BundleCA.crt contains details of the full Unified Assurance trust chain and optionally, the chain from your external certificate authority. To ensure correct functionality:

Check that BundleCA.crt matches the following files:

diff $A1BASEDIR/etc/ssl/BundleCA.crt /etc/containers/certs.d/*/ca.crt
diff $A1BASEDIR/etc/ssl/User-assure1.crt /etc/containers/certs.d/*/client.cert
diff $A1BASEDIR/etc/ssl/Host.crt $A1BASEDIR/vendor/opensearch/config/certs/Host.crt
diff $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/vendor/opensearch/config/certs/BundleCA.crt
diff $A1BASEDIR/etc/ssl/User-assure1.crt $A1BASEDIR/vendor/opensearch/config/certs/User-assure1.crt

Check that BundleCA.crt can validate all certificates in the $A1BASEDIR/etc/ssl directory:

openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/etc/ssl/User-assure1.crt 
openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/etc/ssl/User-api.crt 
openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/etc/ssl/User-kibana.crt 
openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/etc/ssl/User-repl.crt 
openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/etc/ssl/User-root.crt 
openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/etc/ssl/Web.crt 
openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/etc/ssl/Host.crt 
openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt /etc/docker/certs.d/*/client.cert 
openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/vendor/opensearch/config/certs/Host.crt 
openssl verify -verbose -show_chain -CAfile $A1BASEDIR/etc/ssl/BundleCA.crt $A1BASEDIR/vendor/opensearch/config/certs/User-assure1.crt

Title and Copyright Information

Security Guide

G49436-01