Trust and Identity Certificate administration

Last Updated : Oct 17, 2025 |
Prolog information
Metadata
Keywords:
You can administer both Trust Certificates and Identity Certificates for Avaya Breeze® platform.
Identity Certificates are administered individually for Avaya Breeze® platform clusters. Five default Identity Certificates are generated as part of the Avaya Breeze® platform OVA deployment process. You can replace a default certificate with a certificate from a well-known certificate authority.
The Security Module (ASSET) HTTP certificate is the one that is visible to applications and endpoints. If using HTTPS with hostname validation checks, you will need to replace the default ASSET HTTP certificate. When replacing the certificate, edit the Subject Alternative Name field to include both the FQDN assigned to the Avaya Breeze® platform server and the FQDN assigned to the cluster.
For instructions for replacing a certificate and changing the Subject Alternative Name (SAN), see Replacing an identity certificate.
Note:
Starting with Avaya Breeze® platform 3.9.0.3, hostname validation behavior has changed. Subject Alternative Name (SAN) entries are now mandatory in all Identity Certificates. The Common Name (CN) alone is no longer sufficient when SAN is missing. Ensure that FQDN is resolvable from all systems accessing the Avaya Breeze® platform.
Entities that access Avaya Breeze® platform via HTTPS must be able to resolve the Subject Alternative Name (SAN) entries in the certificate with the Fully Qualified Domain Names (FQDNs) of the Avaya Breeze® platform nodes. If you use the default certificates generated by System Manager, the CN in the certificate will look like: <serverHostName>-sm100.<domain>, where host and domain are those specified when you installed the server (or specified during CEnetSetup). If a different certificate has been installed, the FQDN is whatever was specified in CN and/or SAN when generating that certificate.
If you change the Avaya Breeze® platform hostname or domain name, you need to re-create and install the certificates with updated CN and SAN. For more information, see Managing Certificates.
To view the Security Module HTTPS Certificate details, including the CN, for the Avaya Breeze® platform server, see Viewing Identity Certificate details.
To resolve the certificate CN or SAN fields with the FQDN, take one of the following actions:
  • Enter the FQDN of each Avaya Breeze® platform node in your DNS server.
  • Populate the host file of each entity with the FQDN of each Avaya Breeze® platform node that it will access.
    Note:
    You can edit the Avaya Aura® Media Server host files through the Avaya Aura® MS Element Manager. For more information, see Configuring Avaya Aura® Media Server name resolution (alternative 1).
You can administer the Trust Certificates for each Avaya Breeze® platform cluster or a single Trust Certificate can be assigned simultaneously to all the clusters.
For more information about Trust and Identify Certificates, click Help on the System Manager interface and select Managing Certificates. For detailed information about migrating from the Avaya Certificate Authority to a Well-known Certificate Authority, see Avaya Aura® Certificate Migration.

About WebSphere Identity Certificate:

The OVA deployment of Avaya Breeze® platform 3.9.0.3 and higher automatically includes the minimum required SAN fields. For systems upgraded from earlier releases (for example, 3.9.0.2), the existing certificates are typically retained. In most cases, no action is required unless the existing Identity Certificate does not include Avaya Breeze® platform Management FQDN (mgmt-fqdn) and its corresponding IP address in SAN field. The WebSphere identity certificates that do not contain this SAN value will not function correctly. When replacing the certificate, edit the Subject Alternative Name field to include the Breeze Management FQDN assigned to the Avaya Breeze® platform server.
Related links
Certificate administration