Skip to Main Content
AVEVA™ PI System™ Feedback Portal

Welcome to our feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Status No status
Categories Data Archive
Created by Lubos Mlcoch
Created on Feb 25, 2026

Support DNS Alias–Only Certificates for RSSO AIM

Support DNS Alias–Only Certificates for RSSO AIM

Issue

When configuring AVEVA Identity Manager (AIM) on a Redundant Single Sign-On (RSSO) node (PI Server 2024 R2, PCS 8.2.1), the TLS certificate must include the machine FQDN in the SAN list.

Certificates that contain only DNS aliases — even when those aliases correctly resolve to the host and represent the official service endpoint — are rejected.

Enhancement Request

RSSO AIM must support TLS certificates that contain DNS aliases in the SAN list without requiring the internal machine FQDN to be included.

The current implementation enforces an unnecessary dependency on internal hostnames and breaks common enterprise security and PKI design principles, where:

  • Services are exposed via approved DNS aliases

  • Internal machine names are intentionally abstracted

  • Certificate issuance policies prohibit inclusion of internal FQDNs

Requiring the machine FQDN in the SAN list is not aligned with modern enterprise TLS practices and creates avoidable architectural constraints.

This behavior should be corrected so that RSSO AIM validates certificates based on the configured service endpoint rather than enforcing the underlying machine name.

The product should support standard, enterprise-grade certificate deployment models without requiring internal hostname exposure or design compromises.

  • Attach files