Environment
Situation
Various Reflection for the Web components use security certificates. This technical note describes how each component uses the certificate, suggests what type of certificate to use, and describes how to implement the certificate.
Resolution
About Security Certificates
Security certificates (also known as server certificates, site certificates, digital certificates, or SSL certificates) are used as part of the authentication process. Certificates are either self-signed or signed by a Certificate Authority (CA). This technical note suggests the kind of certificate (self-signed or CA-signed) that is most appropriate for each Reflection for the Web component.
Other Factors Affecting Security
The administrator must maintain physical security of the management server and proxy server. That is, no one other than the administrator should be able to physically access the servers, and no unauthorized individuals should be able to access the key store folders on the server. The security of the servers is important to prevent compromise of the certificates.
Summary Table
The following table summarizes the information in this technical note. Click the component link for detailed information about a particular component.
| Component |
Party Authenticating |
Party Being Authenticated |
CA- or Self- signed* |
| Web Server |
Browser |
Web server that management server is running under (for example, Tomcat) |
CA |
| Reflection Management Server |
Security Proxy |
Emulator Applet. Authorization token
passed to emulator applet and then to proxy is authenticated as having
come from the management server |
Self-signed |
| Security Proxy Server |
Emulator applet |
Security proxy server |
Self-signed, if Reflection for the Web only |
| Host |
Emulator applet |
Host |
Self-signed, if Reflection for the Web only |
| Client |
Security proxy or host |
Emulator applet |
Either |
| Secure LDAP (5.1 or higher) |
Management server |
LDAP server |
Either |
| Metering Server |
Management server and client’s browser |
Metering server |
CA |
Web Server
The web server certificate (also known as a site certificate or SSL certificate) is used to authenticate the web server to the client browser. A web server certificate is required to use HTTPS for the connection between client browsers and the web server.
CA-signed or Self-signed
The automated Windows installation for Reflection for the Web generates a self-signed certificate for Tomcat (the default web server and servlet runner). The self-signed certificate causes the browser connecting to the Tomcat web server to display an untrusted certificate warning because the self-signed certificate is not trusted by the browser. The easiest way to eliminate the untrusted certificate warning is to upgrade this self-signed certificate to a CA-signed certificate.
How to Implement
For instructions on upgrading the Tomcat self-signed certificate to a CA-signed certificate, see KB 7021429. For other web servers or application servers, use the tools specific to those servers. If your web server is HTTPS enabled, it is likely that a CA-signed certificate is already being used.
Reflection Management Server
The Reflection management server certificate enables the Reflection security proxy server to verify that users are authorized to connect to hosts through the proxy server. The client authorization feature, which is turned on in the Reflection security proxy server by default, ensures that users cannot connect to hosts through the proxy server without a management server certificate.
When a user launches a secure session, the Reflection management server authenticates the user using the access control mechanism enabled in the Administrative WebStation, and sends an authorization token to the emulator applet. The emulator applet presents this authorization token (which is signed by the Reflection management server’s private key) to the Reflection security proxy server. If client authorization is turned on in the security proxy server, the security proxy server verifies the token’s digital signature to confirm that the token came from the Reflection management server. If this authentication is successful, the connection is allowed.
CA-signed or Self-signed
The automated Windows installation for Reflection for the Web generates a self-signed Reflection management server certificate. There is no advantage to using a CA-signed certificate.
How to Implement
A self-signed Reflection management server certificate is generated during an automated install.
To use a CA-signed certificate you must import the certificate and private key. To do this, in the Administrative WebStation, click Security Setup > Certificates tab. In the Administer Reflection Management Server Certificate section, click "Import a signed certificate and private key."
Import the Reflection management server certificate into the security proxy server during the proxy configuration process. See Reflection for the Web's InstallGuide.html for information on running the Security Proxy Wizard.
Security Proxy Server
Note: Beginning in Reflection for the Web 2008, the security proxy server is not included in the Standard Edition.
The security proxy server certificate is used to authenticate the proxy server to the terminal emulator applet.
The security proxy server certificate is imported into the Reflection management server’s trusted certificates store when you import the proxy server settings into the Administrative WebStation's Security Setup > Security Proxy tab. When launching a secure session, the emulator applet retrieves the security proxy certificate from the management server and caches it locally. The emulator applet uses this certificate to authenticate the Reflection security proxy server.
CA-signed or Self-signed
If the security proxy server is being used only with Reflection for the Web emulator clients, then a self-signed security proxy server certificate is sufficient. The emulator applet uses a trusted certificates store that is deployed centrally from the management server, so it is simple to deploy the proxy server's certificate to the trusted certificates store of all the clients.
However, if the security proxy server is being used with Windows-based Reflection clients, such as Reflection for IBM or Reflection for UNIX and OpenVMS, then a CA-signed certificate should be installed on the proxy server. This avoids untrusted certificate errors when the Windows-based Reflection clients attempt to connect to the proxy server.
Whether you use a CA-signed or a self-signed certificate on the proxy server, for maximum security, the option to verify server identity should be enabled on the Administrative WebStation. This option (which is enabled by default) causes the emulator applet to verify the common name on the proxy server certificate. Check this setting on the Administrative WebStation > Security Setup > Security tab. In the Enable Client Verification of Server Identity section, the "Web-based Reflection clients verify the identity of the server in SSL/TLS connections" check box should be selected.
Note: Beginning in version 8.5, there is a serverIdentityOverride applet parameter that can be set to true or false.
How to Implement
A self-signed server certificate is created during the configuration process for the security proxy server, using the Security Proxy Wizard. An option to import a CA-signed certificate is also available. After a certificate for the security proxy server is created or imported, the Reflection Management Server must import its certificate and certain configuration information. This is accomplished by running the import process on the Administrative WebStation's Security Setup > Security Proxy tab.
Host
When using SSL direct to the host, the host certificate is used to authenticate the host to the emulator applet.
The host certificate is stored in the Reflection management server’s trusted certificates store. The emulator applet retrieves the host certificate from the management server and caches it locally. The emulator applet authenticates the host using this certificate.
CA-signed or Self-signed
If the SSL-enabled host is being used only with Reflection for the Web emulator clients, then a self-signed host server certificate is sufficient. The emulator applet uses a trusted certificate store that is deployed centrally from the management server, so it is simple to deploy the host’s certificate to the trusted certificates store of all the clients.
However, if the host is being used with Windows-based Reflection clients, such as Reflection for IBM or Reflection for UNIX and OpenVMS, then a CA-signed certificate should be installed on the host. This avoids untrusted certificate errors when the Windows-based Reflection clients attempt to connect to the host.
Whether you use a CA-signed or a self-signed certificate on the proxy server, for maximum security, the option to verify server identity should be enabled in the Administrative WebStation. This option (which is enabled by default) causes the emulator applet to verify the common name on the host certificate. Check this setting on the Administrative WebStation's Security Setup > Security tab. In the Enable Client Verification of Server Identity section, the "Web-based Reflection clients verify the identity of the server in SSL/TLS connections" check box should be selected.
How to Implement
To import a self-signed or CA-signed certificate and private key to a host, use the tools specific to that host.
Import the host certificate* on the Administrative WebStation > Security Setup > Certificates tab. In the Administer Terminal Emulator Applet Trusted Certificate List section, click "View or modify certificates trusted by the terminal emulator applet." Import the self-signed certificate here.
*Note: The intermediate certificate that issued the host certificate may be used in place of the host certificate.
For a CA-signed certificate, review the Trusted Root Certificate Authorities section on the Security Setup > Certificates tab. In the Administer Terminal Emulator Applet Trusted Certificate List section, click "View or modify certificates trusted by the terminal emulator applet" to confirm that the CA is listed. If not, you can import the CA certificate to the list of trusted certificates.
Client
A client certificate and private key is required when the Reflection for the Web emulator applet connects to either a security proxy server that has client authentication enabled, or to an SSL host that has client authentication enabled. A client certificate enables the security proxy server or host to verify the identity of the client. This type of certificate is not commonly used.
CA-signed or Self-signed
You can use either a CA-signed certificate or a self-signed certificate. The procedure to enable the host to trust the client certificate is specific to each host.
Use the Security Proxy Wizard to import the client certificate(s) to the security proxy server on the Trusted Certificates tab of the wizard.
How to Implement
Import a CA-signed or self-signed client certificate and private key on the Administrative WebStation's Security Setup > Certificates tab. In the Administer Client Certificate section, click "Import a signed certificate and private key." When client certificates are implemented in this way, the client certificate and private key are centrally distributed by the Reflection management server to Reflection for the Web emulator applets, and all Reflection for the Web clients use the same client certificate and private key.
Secure LDAP
This certificate enables the Reflection management server to verify the identity of the LDAP server. The Reflection management server must trust the LDAP server certificate to make an SSL connection to the LDAP server. This certificate is required only when Secure LDAP is being used.
CA-signed or Self-signed
Reflection for the Web supports whatever certificate type the LDAP server is using.
How to Implement
For a CA-signed certificate, review the Trusted Root Certificate Authorities section on the Security Setup > Certificates tab. In the Administer Reflection Management Server Trusted Certificate List section, click "View or modify certificates trusted by the Reflection management server" to confirm that the CA is listed. If not, you can import the CA certificate to the list of trusted certificates.
Import the LDAP certificate (self-signed or not in the CA list) into the Reflection management server trusted certificates store on the Administrative WebStation's Security Setup > Certificates tab. In the Administer Reflection Management Server Trusted Certificate List section, click "View or modify certificates trusted by the Reflection management server."
Metering Server
The Reflection management server must trust the metering server certificate and the client's browser must trust the metering server certificate if HTTPS is being used to access the metering server.
CA-signed or Self-signed
It is recommended that you use a CA-signed certificate, because the client's browser has to trust this certificate. If the metering server is not using a CA-signed certificate, then you must import the metering server's self-signed certificate to all of your client machines.
How to Implement
For a CA-signed certificate, review the following:
- Trusted Root Certificate Authorities section on the Security Setup > Certificates tab. In the Administer Reflection Management Server Trusted Certificate List section, click "View or modify certificates trusted by the Reflection management server" to confirm that the CA is listed. If not, you can import the CA certificate to the list of trusted certificates.
- The trusted certificates store in the client browser. The metering server's certificate must be included in each client's browser certificate store.
Note: If the Reflection management server and the metering server are on the same machine, then the certificate used for the web server (the server’s SSL or HTTPS certificate) is also used for the metering server.
Additional Information
IMPORTANT: The security for Reflection for the Web depends upon the security of the operating system, host, and network environment. We strongly recommend that you evaluate and implement all relevant security service packs, updates, and patches recommended by your operating system, host, and network manufacturers. The recommendations in this note are general guidelines and should be evaluated in the context of your own computing needs and environment.