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
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 premise | Cloud Authentication Service | Hybrid | |
| Issued by | The deployment's internal RSA root CA by default, or your own CA if replaced | RSA, using a public CA | Both |
| Renewed by | You | RSA | You for Authentication Manager, RSA for CAS |
| Main certificates |
|
| All of the above, plus Authentication Manager's trust of CAS |
| Clients must trust |
| The public CA, which most systems already trust | Both |
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
| Problem | Cause | How to avoid it |
| A certificate can't be activated after a migration or database restore | The certificate was issued for the old hostname | Plan 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 another | The client trusts only one server's certificate | Import the root CA certificate on the client so it trusts every instance. |
| Browsers show "not secure" or the wrong hostname | The active certificate doesn't match the hostname being used | Confirm the certificate's subject and subject alternative names include every hostname users connect to |
| An integration stops working after RSA renews a CAS certificate | The integration pinned or trusted the specific old certificat | Trust the public CA rather than a specific certificate. |
| Authentication Manager can't connect to CAS | A proxy is inspecting SSL traffic | Trust the proxy's certificate in Authentication Manager, or exclude CAS traffic from inspection. |
Related information
- RSA Authenticaiton Manager ans self-signed certificates
- How to trust the RSA Authentication Manager Security Console self-signed root CA certificate and precent certificate warnings.
- Certificate management information in the RSA Authentication Manager Administrator's Guide for your product version.
- How to manage RSA Authentication Manager console and virtual host certificates with keytool]
- Documentation on Identity Router configuration.
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.
Related Articles
Certificates and Keys for Service Providers and Identity Providers for the SSO Agent 19Number of Views Error: 'HTTP 500 - Internal Server Error' while performing WebSSO between Asserting Party (AP) and Relying Party (RP) 17Number of Views SecurID Governance & Lifecycle 7.5.2 Patch 10 Release Notes 27Number of Views Error when going into the Event Viewer 28Number of Views RSA Announces RSA Authentication Agent 2.0.1 for Microsoft AD FS Support for Windows Server 2019 18Number of Views
Trending Articles
How to manipulate imported RSA SecurID Software Token(s) on an iPhone or iPad device RSA MFA Agent 2.5 for Microsoft Windows Release Notes How to test RSA Identity Router (IDR) Secure Connector connectivity to the RSA ID Plus Cloud Access Service RSA Authentication Manager 8.9 Release Notes (January 2026) RSA SecurID software token .sdtid file fails to import into RSA SecurID Software Token 5.0 for Windows
Don't see what you're looking for?