RSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition:  8.x all versions

If you correctly follow KB
Unable to access RSA Authentication Manager 8.3 Security Console or Operations Console using CNAME or DNS alias
https://community.rsa.com/s/article/Unable-to-access-RSA-Authentication-Manager-8-3-Security-Console-or-Operations-Console-using-CNAME-or-DNS-alias
to
1. create the alias Cname in DNS so as to resolve to same IP as the FQDN
2. Add Alias to your AM server /etc/hosts file
3. Add alias to ims.trustedhost.whitelist.custom with /opt/rsa/am/utils/rsautil -a add_config
4. restart AM services

So that your Help Desk Administrators are able to access the AM Security Console by an alias, e.g.
Security Console FQDN = https://Provo-ut-charlie1.company.com:7004/console-ims
Security Console Cname Alias/SAN = https://am-primary.company.com:7004/console-ims

The alias https://am-primary.company.com:7004/console-ims redirects to the FQDN https://Provo-ut-charlie1.company.com:7004/console-ims and user successful authenticate,

BUT the browser does not display the Security Console page, it errors out with <alias> redirected you too many times. ERR_TOO_MANY_REDIRECTS

Note: Alias shortcut https://am-primary.company.com/sc works, it is only the full Alias URL that fails.

The Security & Operations Console alias scenarios on port 7004 & 7072 were never tested by Engineering, never designed for, and never documented as a supported configuration. In recent times it happens to partially work — the login page loads — but fails at the post-login redirect step.

Can ims.trustedhost.whitelist.custom fix this? - Adding the alias to ims.trustedhost.whitelist.custom tells AM that the alias is a known, safe hostname. But the redirect loop problem is on the browser side. The browser holds a cookie scoped to <FQDN>. When redirected to <Alias>, the browser follows the HTTP cookie specification — it checks the cookie's fqdn, sees it does not match the alias, and simply does not send it. The browser does not consult AM's whitelist. The browser does not know what AM trusts. The browser only follows HTTP rules.

Can the session cookie be scoped to both FQDN and alias simultaneously? - No. This is a fundamental HTTP specification limitation — not an AM limitation.
The HTTP specification says a cookie can only have one Domain attribute. A single cookie cannot cover two unrelated hostnames. The browser will only send the cookie to the domain it was set for.

There is no configuration in AM, no cookieDomain setting, no whitelist entry that can override this. It is the browser enforcing the HTTP standard.

Any resolution for this problem would require a code change to the AM browser filters and as of publication of this Knowledge Base, KB Article, March 27, 2026 that has not happened.

There is a work-around, see below.

Using the /sc and /oc shortcuts with the CName Alias URL works after successful authentication.

In our example where the Alias that fails with ERR_TOO_MANY_REDIRECTS is

https://am-primary.company.com:7004/console-ims

Using the /sc shortcut, 

 https://am-primary.company.com/sc works, as would the Ops Console short cut https://am-primary.company.com/oc also work. 

If a replacement console certificate has been imported into the AM appliance, that Certificate should have the FQDN in the Subject as Common Name, CN = and the CName alias as a Subject Alternate Name, SAN.