Reflection for the Web Certificate, Token, and Security Errors

  • Document ID:7022334
  • Creation Date:14-Sep-2006
  • Modified Date:25-Mar-2018
    • Micro Focus Products:
      Reflection for the Web

Environment

Reflection for the Web 2014 (All Editions)
Reflection for the Web 2011 (All Editions)
Reflection for the Web 2008 (All Editions)

Situation

This technical note provides steps for troubleshooting the following common security-related Reflection session connection errors.

  • "The application's digital signature has an error"
  • "Expired or invalid authorization token"
  • "Missing authorization token"
  • "SSL server identity does not match the common name in the certificate"
  • "Certificate found but it is not yet valid or has expired"
  • "TLS alert: Certificate expired"
  • "Creation of master secret failed” followed by “Connection to host failed”
  • "Certificate is not trusted" followed by "Connection to host failed"
  • Security Alert Pop-Up
  • Browser Security Warning Pop-Up

Resolution

About Reflection for the Web and Security

Depending on how Reflection for the Web is configured, the authentication process may use any or all of the following security certificates: web server, Reflection management server, security proxy server, host, client, LDAP server, or metering server.

About Tokens

When sessions are configured to use the security proxy with client authorization enabled (the default), a client authorization token is required to launch a secure session. The authorization token assures that the client has been authorized for the session by the management server and is signed by the management server’s certificate.

For further information about Reflection and security certificates, see KB 7022224.

Troubleshooting Security Errors

The following sections describe common causes of these errors and explain how to resolve each issue. Follow the recommendations for the error you are seeing.

"The application's digital signature has an error"

Beginning on April 14, 2012, Reflection for the Web 2008 users may experience the following error when running Reflection for the Web.

View Full Size
Figure 1: Reflection for the Web certificate error, Figure 1: Reflection for the Web certificate error, "The application's digital signature has an error."

Cause

When the Sun Java plug-in loads the Reflection for the Web applet, it checks the code-signed certificate from Thawte, which expired on April 14, 2012.

Workaround

Although the digital certificate has expired, it is still valid. Reflection for the Web will continue to work if users click Run to bypass the error. Select the "Always trust content from this publisher" check box to stop the warning dialog from being displayed each time you connect.

Upgrade to Reflection for the Web 2011 to address this issue.

"Expired or invalid authorization token"

This error can be caused by any of the following situations:

  • The token has expired.

By default, the authorization token is valid for 20 minutes. If you browse away from the terminal session and return after 20 minutes, or if you attempt to reconnect to the host in a terminal window after 20 minutes, you will receive this error. To clear the error, relaunch the session.

To change the default value, open the Security Proxy Wizard, click the Advanced Settings tab, and modify the Session token valid timeout field.

  • The security proxy does not have the current certificate.

The current Reflection management server certificate has not been imported into the security proxy.

To verify that the correct certificate has been imported into the security proxy, open the Security Proxy Wizard. On the Trusted Certificates tab, highlight the management server certificate. Check the certificate details against the details of the certificate in the management server.

To view the management server certificate, in the Administrative WebStation, click Security Setup. On the Certificates tab, look at the certificate details listed under Administer Reflection Management Server Certificate. Verify that the fingerprint is the same. If the certificates differ, re-import the management server certificate: in the Security Proxy Wizard, click the Trusted Certificates tab, and select Import.

  • The system clocks are out of synchronization.

Verify that the clocks on the management server, security proxy, and the client machines are set to the same time. A difference of more than five minutes may cause this error.

"Missing authorization token"

This error can be caused by either of the following situations.

  • The management server certificate has expired.

This error occurs if the management server certificate is expired at the time of token generation.

The management server certificate signs the authorization token. If the certificate has expired, tokens cannot be generated.

To verify the expiration date, open the Administrative WebStation and click Security Setup. On the Certificates tab, examine the certificate details under Administer Reflection Management Certificate.

If the certificate is expired, create a new certificate on the Certificates Tab under Administer Reflection Certificate. Once the new certificate has been generated, import it through the Security Proxy Wizard by clicking Import on the Trusted Certificates tab.

  • The system clocks are out of synchronization.

Verify that the clocks on the management server and security proxy machines are set to the same time.

"SSL server identity does not match the common name in the certificate"

This message indicates that the common name used in an SSL host certificate does not match the server name configured in the Reflection for the Web session.

To resolve this problem compare the common name in the certificate with the security proxy name or host SSL server name (if configured for direct SSL) with the Reflection for the Web session configuration.

To check the security proxy certificate, follow these steps:

  1. Open the Security proxy wizard.
  2. On the Security Proxy Certificates tab, view the common name field within the distinguished name details.
  3. On the Advanced Settings tab, verify the name of the security proxy server shown at the bottom of the screen.

If necessary, modify the name to match the common name of the certificate, or delete the old certificate and create a new certificate to match the server name.

To check a host’s SSL certificate, follow these steps:

  1. From your browser, establish an HTTPS connection to the host over the SSL port. Use the same name configured in the Reflection for the Web session.
  2. If a dialog box opens warning that the name on the certificate does not match the name of the site, click View Certificate.

The information shown in the "Issued to" field is the common name in the certificate.

  1. If the common names do not match, adjust the name used in the Reflection for the Web session to match the certificate or obtain a new certificate with the correct common name.

The java console can also be used to check either the security proxy or host SSL certificate. The certificate common name is displayed in the java console as part of the TLS handshake.

If it is not possible or desirable to match the common name of the certificate to the server name, you can disable server identity checking. However, this bypasses this security check and decreases your network security.

Globally: To disable Server Identity Checking globally, for all sessions, open the Administrative WebStation, click Security Setup. On the Security tab, clear the Enable server identification verification check box.

Per Session: To disable Server Identity Checking on a per session basis, you can override the global setting by using the serverIdentityOverride applet parameter. For information about this parameter, see the Administrative WebStation help. Search for "applet attributes and parameters."

"Certificate found but it is not yet valid or has expired"

"TLS alert: Certificate expired"

These errors typically relate to the security proxy certificate, or a host’s SSL certificate if configured for direct SSL. Verify that the certificate has not expired and that the clocks on management server, security proxy, and client machines are set to the same time.

"Creation of master secret failed” followed by “Connection to host failed”

This error indicates that your java clients may not have the high encryption security pack installed.

To alleviate this problem, choose one of the following solutions (steps below):

  • Install the java high encryption security pack on each client, or
  • Disable 256-bit AES on your host, or
  • Disable 256-bit AES in the Reflection for the Web client session (version 7.01 or higher). 128-bit AES will not cause this error.

Install the java high encryption security pack on each client

By default, the Sun Java Plug-in does not support 256-bit AES. To enable your workstations to support 256-bit AES connections:

  1. Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files (5.0) from:

http://java.sun.com/javase/downloads/index_jdk5.jsp

or

http://java.sun.com/javase/downloads/index.jsp

  1. Install the JCE Unlimited Strength Jurisdiction Policy Files on each workstation that uses the Sun Java Plug-in and the Reflection for the Web clients.

For further details, see the readme.txt file that comes with the JCE Unlimited Strength Jurisdiction Policy Files.

Disable 256-bit AES on your host or security proxy

Refer to your host documentation for information about disabling 256-bit AES on your host. If using the security proxy, follow these steps to check the cipher suite on the security proxy certificate.

  1. Start the Security Proxy Wizard.
  2. On the Proxies tab, select the port and click Modify.
  3. Under cipher suites and certificates, select the certificate and click Modify.
  4. Under Cipher Suite properties, if the Cipher Suite is RSA or DSA with 256 AES, select a different option.
  5. Click Save.

After making these changes, you must export the new certificate and settings to the management server.

Disable 256-bit AES in the Reflection for the Web client session (7.01 or higher)

To disable 256-bit AES in version 7.01 or higher of the Reflection for the Web client session, follow the steps below.

Note: It is not necessary to disable 128 bit AES.

  1. Open the Administrative WebStation and click Session Manager.
  2. Click the session name to open the session configuration page.
  3. Click Applet Parameters.
  4. In the Custom parameters section, enter these values:

Parameter: sslAES256

Value: False

  1. Click Add to add this parameter and value to the Current Parameters list.
  2. Click Continue, and then click Save Settings.

"Certificate is not trusted" followed by "Connection to host failed"

This error indicates that the security proxy or host SSL (if the host is configured for SSL) certificate has not been imported into the Reflection management server.

To verify that the certificate is listed in the Administrative WebStation:

  1. In the Administrative WebStation, click Security Setup.
  2. On the Certificates tab, under Administer Terminal Emulator Applet Trusted Certificate List, click View or modify certificates trusted by the terminal emulator applet.

If you are using static, unprotected sessions (sessions that are not listed in the Links List) that are configured to go through the security proxy, this error occurs because the trustedps.pfx file is not downloaded to the client. The trustedps.pfx file contains the security proxy certificate. To correct the problem, add the following parameter to the .html for the session, which results in an automatic download of the trustedps.pfx file:

<param name="servletURL" value="http://<server>:<port>/rweb/">

Security Alert Pop-Up

Users get a browser Security Alert pop-up when attempting an HTTPS connection to the web server. These alerts are not fatal. If the client accepts the certificate, the connection is successful.

Three Security Alert pop-ups could occur, depending on the condition. Follow these suggestions to resolve these issues:

  • The web server’s certificate is not from a trusted source.

This can occur if the certificate is “self-signed” (not from a CA such as Verisign or Thawte) and has not been imported into the client browser’s trusted certificates store.

To resolve this issue, purchase a CA signed certificate for the web server or install the certificate into the client browser’s trusted certificate store. To install the certificate, click View Certificate in the alert pop-up dialog box, and the select Install Certificate.

  • The web server’s certificate is expired or not yet valid.

To resolve this issue, select View Certificate in the alert pop-up dialog box. On the General tab, examine the validity period. If the certificate has expired, purchase or create a new certificate. If the certificate appears to be within the validity period, verify that the clocks on the web server and client machines are set to the same time.

  • The name on the certificate is invalid or does not match the web site’s name.

To resolve this issue, change the name used in the URL or create or purchase a certificate with a common name that matches the name of the web site.

Browser Security Warning Pop-Up

Users are getting a Warning – Security pop-up about the Reflection for the Web applet. This warning is a security feature, notifying the client that a signed applet is being downloaded. The applet is signed by a CA (Thawte or Verisign, depending on the version of Reflection for the Web), which is a trusted company.

If the Reflection for the Web software is older than version 7.0, the security certificate may have expired. Because it is not feasible for Attachmate to resign and reissue older product certificates, there is no solution for an expired product certificate.

To work around this issue, either upgrade to the current version of Reflection for the Web, or click Yes each time this warning is displayed. Click Always to eliminate future warnings about this certificate.

1958_0.gif

Further Troubleshooting

If you encounter an error message that is not resolved by the suggestions provided in this technical note contact Attachmate Technical Support. Note: To receive support, your organization's Reflection for the Web maintenance agreement must be current.

For contact information, see https://support.microfocus.com/contact/.

When you contact support, please have the following information available:

  • A Java console that captures the error condition (for details on obtaining a java console, see Technical Note 1433.
  • A screen shot or the exact wording of error message(s).
  • A debug log file.

Follow the steps below to create a debug log file specific to your issue.

For security proxy related issues, enable debugging:

  1. Open the Security Proxy Wizard.
  2. On the Logging tab, select all of the filters.
  3. Click Save.
  4. Recreate the problem.
  5. Locate the log file in the ReflectionServer\Securityproxy\logs folder.
  6. Make a copy of the log file and be prepared to forward it to Attachmate Technical Support.

For access control and Administrative WebStation access issues, enable debugging:

  1. Open ReflectionServer\ReflectionData\properties\log.properties.
  2. Change the line that reads:
log4j.rootCategory=warn, trace

to this (change is noted in red):

log4j.rootCategory=debug, trace
  1. Save the file.
  2. Restart the Reflection Server. For Microsoft Windows, stop and restart the server from Windows Services. On other platforms, stop and restart the servlet runner, typically Tomcat.
  3. Recreate the problem.
  4. Locate the trace.log file in the ReflectionServer\ReflectionData\log\ folder.
  5. Make a copy of the logfile and be prepared to forward it to Attachmate Technical Support.

For emulation and display issues, obtain an event trace:

  1. Launch the session with Advanced or Administrative menu level set, or launch it from Session Manager inside the Administrative WebStation.
  2. Go to Help > Start Trace and provide a name for the trace file.
  3. Recreate the problem.
  4. Go to Help > Stop Trace.
  5. Make a copy of the resulting .evt file and be prepared to forward it to Attachmate Technical Support.

Additional Information

Legacy KB ID

This document was originally published as Attachmate Technical Note 1958.