Comparing certificates used in RSA Authentication Manager, Cloud Authentication Service, and hybrid deployments
Originally Published: 2026-09-29
Last Modified: 2026-09-29
Article Number
000074112
Applies To

RSA Product Set: SecurID, ID Plus
RSA Product/Service Type: Authentication Manager, Cloud Authentication Service, Identity Router, MFA Agent
RSA Version/Condition: 8.x

Issue

The key difference is ownership of the certificates:

  • Authentication Manager on-premises: You own and manage all certificates.
  • Cloud Authentication Service: RSA manages the service certificates. You manage only the certificates for your integrations.
  • Hybrid: You manage the Authentication Manager certificates, RSA manages the CAS certificates, and Authentication Manager must trust CAS.

Comparison

Authentication Manager on premiseCloud Authentication ServiceHybrid
Issued byThe deployment's internal RSA root CA by default, or your own CA if replacedRSA, using a public CABoth
Renewed byYouRSAYou for Authentication Manager, RSA for CAS
Main certificates
  • Console
  • Virtual host for a load balancer. If configured the web tier will present the VH certificate. With no virtual host, the web tier uses a certificate for its' own name from the Authentication Manger internal root CA
  • Web tier
  • RADIUS server
  • Identity source trust
  • Tenant URLs
  • SAML signing
  • Identity router
All of the above, plus Authentication Manager's trust of CAS
Clients must trust
  • Internal root CA, or
  • Your CA if replaced
The public CA, which most systems already trustBoth

Authentication Manager certificates

  • Internal root CA Created when the primary instance is installed. It signs the server certificates for the primary and every replica. Clients should trust this root CA rather than an individual server's certificate, so they keep working when they connect to a different instance.
  • Console certificate Used by the Security Console, Operations Console, Self-Service Console, and the RSA SecurID Authentication API (port 5555). You can replace the default certificate with one issued by your own CA in the Operations Console under Deployment Configuration > Certificates > Console Certificate Management.
  • Virtual host certificate Used when Authentication Manager is accessed through a load balancer or virtual hostname. The certificate must match the hostname users connect to.
  • Web tier Presents the virtual host certificate to users connecting through the DMZ.
  • RADIUS server certificate Required only for EAP authentication methods, such as PEAP.
  • Identity source certificates When Authentication Manager connects to Active Directory over LDAPS, import the certificate of the CA that issued the domain controllers' certificates under Deployment Configuration > Certificates > Identity Source Certificate Management.
  • Classic authentication agents use the node secret, not certificates, to communicate with Authentication Manager.

Cloud Authentication Service certificates

  • Tenant certificates RSA manages and renews the certificates for the Cloud Administration Console, the SSO Portal, and authentication endpoints. You don't need to install or renew them.
  • SAML signing certificates SSO applications use signing certificates that you manage. When you rotate one, update the service provider with the new certificate.
  • Identity Router certificates The Identity Router can use its own certificate, for example for a custom SSO Portal hostname. It must also trust your domain controllers' CA for LDAPS connections.
  • MFA Agents and other clients Clients that connect directly to CAS rely on the public CA, so no certificate import is usually needed. The exception is a network proxy or firewall that inspects SSL traffic, since it replaces the certificate the client sees.

Hybrid deployments

In a hybrid deployment, Authentication Manager is connected to the Cloud Authentication Service. Keep in mind:

  • Authentication Manager connects to CAS over HTTPS (port 443). It must trust the CAS certificate chain. If a proxy inspects this traffic, Authentication Manager must also trust the proxy's certificate, or the proxy must be configured to skip inspection for CAS traffic.
  • The embedded Identity Router connects to Authentication Manager. Authentication Manager's certificates must match the hostnames it uses.
  • Where the MFA Agent connects determines what it must trust. An agent connecting to Authentication Manager on port 5555 needs the Authentication Manager root CA. An agent connecting to CAS uses the public CA.
  • There are two renewal schedules. RSA renews CAS certificates on its schedule, and you renew Authentication Manager certificates on yours. Track both.

Common problems and how to avoid them

 

ProblemCauseHow to avoid it
A certificate can't be activated after a migration or database restoreThe certificate was issued for the old hostnamePlan certificates before migrating. Request certificates for the new hostnames, or restore to a server with the original hostname first and rename it afterward.
A client works with one Authentication Manager instance but fails with anotherThe client trusts only one server's certificateImport the root CA certificate on the client so it trusts every instance.
Browsers show "not secure" or the wrong hostnameThe active certificate doesn't match the hostname being usedConfirm the certificate's subject and subject alternative names include every hostname users connect to
An integration stops working after RSA renews a CAS certificateThe integration pinned or trusted the specific old certificatTrust the public CA rather than a specific certificate.
Authentication Manager can't connect to CASA proxy is inspecting SSL trafficTrust the proxy's certificate in Authentication Manager, or exclude CAS traffic from inspection.
 

 

Notes

By default, Authentication Manager issues its server certificates from an internal root CA that is created when the primary instance is installed. These default certificates are a secure choice for many deployments.

 

  • The keys are generated on the server. Each instance's private/public keypair is created with a randomly generated value on that server during installation and never leaves it.
  • Trust is limited to your deployment. The internal root CA exists only in your deployment and issues certificates only to your Authentication Manager instances. Clients that trust it aren't trusting certificates issued to anyone else.
  • No dependency on an outside CA. A problem with a public or enterprise CA doesn't affect your Authentication Manager certificates.
  • Replicas are handled for you. New replicas get certificates from the same internal root CA, so every instance is trusted consistently.