Overview
We receive a number of inquiries regarding AM network endpoints that offer Transport Layer Security (TLS, the replacement for SSL) with host (server) certificates signed by a self-signed root certificate. These network endpoints are used for internal communication between components within the product. They are often identified as “security vulnerabilities” because most network security scanners do not understand AM’s security model. Many of the network endpoints used by AM are a “closed system” and are only used by other AM components. These are not endpoints used by web browsers or by any other external system. While it makes sense to require that network endpoints used by web browsers not utilize host certificates with untrusted, self-signed root certificates, this does not apply to internally controlled, inter-component network connections. 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) and another set for use between components.
Console Certificates
The certificates used for the web-based Security Console are created as a convenience to get the server up and running, and these can be replaced by generating a Certificate Signing Request (CSR), having the request signed by a certificate authority of the customer’s choice, and importing the signed certificate back into Authentication Manager. Once activated, these certificates replace the certificates generated at installation. Console certificates are generated for use with the Security Console and servers deployed in the Authentication Manager “Web Tier” such as the Self-Service Console, the Risk Based Authentication web interface, and the CT-KIP service endpoints. In each case, having a TLS certificate signed by a trusted certificate authority is an important element of system security, because end users are relying upon the web browsers built-in list of Trusted Root Certification Authorities to validate the authenticity of the server to which they are connecting (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 AM components and are never used with end user web-browsers. Each AM 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 AM 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 previously, the use of self-signed certificates has been reported in a number of issues and “requests-for-enhancement” reported to RSA Customer Support (AM-28955, AM-30231, and AM-30835, to name a few). 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.
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 AM server and are not used for web-browser interfaces.
[1] Self-signed certificate, Wikipedia, Retrieved 2017-05-08.
