Overview

Authentication Manager uses two categories of TLS certificates: replaceable certificates for browser-facing consoles and internally trusted certificates for communication between product components. This document explains why internal certificates are signed by the deployment’s private root certificate authority, why scanners may flag them, and why their use does not represent the same risk as an untrusted certificate on a public-facing service.

RSA receives a number of inquiries regarding Authentication Manager network endpoints that offer Transport Layer Security (TLS, the replacement for SSL) with host (server) certificates signed by a self-signed root certificate.

These endpoints support communication between Authentication Manager components. Security scanners may identify their certificates as vulnerabilities because the scanners evaluate them as generally accessible TLS services rather than as endpoints within Authentication Manager’s limited security domain. Many of these endpoints operate as part of a closed system: they are used only by Authentication Manager components, not by web browsers or external systems. Requirements for publicly trusted certificates on browser-facing services therefore do not apply in the same way to these controlled, inter-component connections.

The RSA 'self-signed' certificates, also called internal “plumbing” certificates, are not untrusted within the limited security domain of an Authentication Manager deployment. They are of a strictly limited security domain; one that is not public or general in nature, not applicable to the Internet or web or e-commerce.

The use of these internally controlled certificates increases the security of the system by reducing the possibility of a rogue server or service being created.

TLS Server Certificates

During installation of a new primary instance, RSA Authentication Manager generates a new internal root certificate authority (CA) and creates new TLS host certificates for the new primary instance. It creates two sets of certificates, one for the web-based Security Console (and other consoles), e.g. TCP port 7004 and another set for use between components: 'plumbing' certs,  and those used for replication traffic on TCP port 7002.

Console Certificates

The certificates used for the web-based Security Console and the Internet-facing Web-Tier are created as a convenience to get the server up and running. They are of the limited trust Security Domain of Authentication Manager. These two certificates can be replaced by generating a Certificate Signing Request (CSR), for either;

• The Security Console using TCP port 7004. Also used by MFA agent to authenticate on TCP port 5555
• The Web Tier Virtual Host, using TCP port 443

That CSR request can be signed by a certificate authority of the customer’s choice, and the signed certificate Response file can be imported back into Authentication Manager.

After activation, customer-signed certificates replace the certificates created during installation. Console certificates support the Security Console and Authentication Manager Web Tier services used by Internet or web-based users, including the Self-Service Console and the CT-KIP service for secure, end-to-end delivery of RSA software token seed data to the smartphone-based RSA Authenticator app. For these browser-facing services, a certificate signed by a trusted CA is an important security control because users rely on the browser’s built-in list of trusted root certification authorities to validate the server’s identity, as shown in Figure 1.

Figure 1 - Internet Explorer Trusted CA Interface

Internal “Plumbing” Certificates

The certificates used between the components are sometimes referred to as “plumbing” certificates. These certificates are used to secure communications between Authentication Manager components and are never used with end user web-browsers. Each Authentication Manager component verifies the authenticity of the remote server by making sure that server’s internal certificate is signed by the self-signed, special-purpose root CA certificate generated at the installation of the first primary instance. Since these connections are not used by web browsers, using self-signed certificates has no detrimental impact on the security of the system. To the contrary, this “closed system” increases the overall security by ensuring that Authentication Manager servers will never trust another server presenting a server certificate signed by some external CA outside of the system’s control. The process of creating a new replica instance requires administrative credentials. It is only through this process that new internal server certificates are created for servers within a deployment. Without this control, any actor that can request a SSL server certificate signed by the external CA (often anyone within the same organization) would be able to potentially create a rogue AM server.

A self-signed certificate based public key infrastructure (PKI) provides security advantages:

There are at least two reasons why a self-signed certificate based PKI may have decreased overall risk. The first, also shared with private PKI systems, it that they avoid the problems of trusting third parties that may improperly sign certificates. [Secondly,] Self-signed certificate transactions usually present a far smaller attack surface, by eliminating both the complex certificate chain validation and CA revocation checks like CRL and OCSP [1].

Reported Issues

As mentioned, the use of self-signed certificates has been reported in a number of issues and requests for enhancement reported to RSA Customer Support. These requests are generally associated with network ports 7002, 1813, and 7022, all of which are only used for internal communication and are not used in end user, web-browser interfaces. These ports present their certificates to openssl requests, but do not accept HTTP or HTTPS.

Depending on the services selected, some customers may also see TLS network connections being offered by legacy protocols at ports 5550 and 5580. These are also only used internally between RSA authentication agents and the Authentication Manager  server and are not used for web-browser interfaces. Newer versions of Authentication Manager allow these ports to be disabled.
 * * * 

[1] Self-signed certificate, Wikipedia, Retrieved 2017-05-08.

•    Does the RSA Authentication Manager Appliance require its Root CA certificate for internal application communication? YES
•    Is replacing or modifying this certificate supported? NO, this is not recommended.
•    Will any attempt to replace or modify this certificate adversely impact the functionality, stability, or supportability of the RSA Authentication Manager Appliance or its applications? YES
•    Is RSA's recommended approach to retain the existing internal certificate configuration? YES

•    If you replace your AM Appliance Console Certificate, do you need to update/trust that certificate in any Admin SDK connections to TCP port 7002. NO, the Admin SDK uses internal "plumbing" cert on its API connections.

•    If you replace your AM Appliance Console Certificate, do you need to update/trust that certificate on your MFA agents? YES, you need to trust the Root CA

RSA recommends leaving the Internal "Plumbing" certificates in tact as 'Limited Trust' Certificates, which are fully supported by RSA.

RSA recommends replacing the Web Tier Virtual Host certificate for Self-Service Console remote access or CTKip software token seed downloads via the Internet or Web,

There is no RSA recommendation that the Security Console Certificate be replaced.

RSA Security Console access on TCP port 7004 is part of the Limited Trust Security Domain of Authentication Manager, which fits well with the Internal 'Plumbing' certificate Security Footprint.

If you do not replace your AM console certificate, it makes sense to have your Help Desk Administrator browsers  "trust" the Root CA signer certs for any AM deployments they manage. 

MFA agents that authenticate to an AM Appliance on TCP port 5555 will validate the Root CA signer Certificate for the Console Certificate, i.e. the agent needs to 'trust' the Root CA for your console Cert whether it is replaced or not.

If you replace/update the replaced AM Console Certificate a second time, e.g. the cert expired after a year or two, if that 2nd replacement is signed by the same Root CA your MFA agent will be good. But if you change Root CAs for the console replacement cert, you will need to update your MFA agents.