000034445 - Unable to login into RSA Identity Governance and Lifecycle with secure HTTPS with time out error

Document created by RSA Customer Support Employee on Jan 5, 2017Last modified by RSA Customer Support Employee on Apr 22, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000034445
Applies ToRSA Product Set: RSA Identity Governance and Lifecycle
RSA Product/Service Type: Appliance
RSA Version/Condition: All
O/S Version: Red Hat Enterprise Linux Server 
 
IssueUnable to login into the RSA Identity Governance and Lifecycle UI with secure HTTPS after completing the 7.0.1 installation on Red Hat, while RSA Identity Governance and Lifecycle is running.  When you attempt to load a page, it takes too long to respond and times out with the following messages:
 
This site can't be reached
ERR_CONNECTION_TIMED_OUT

 

User-added image


This article describes the procedure of how to apply the fix for the problem you encounter with running RSA Identity Governance and Lifecycle  on WildFly due to a firewall issue, after initial deployment.
Note : There are some other scenarios/reasons that can prevent access to the Aveksa UI, which are discussed in the Notes section below.  
CauseA software appliance installation does not open and redirect required TCP ports in the firewall on Red Hat.  We need to open the required TCP ports on the firewall to allow communications with RSA Identity Governance and Lifecycle that are required by the software for internal and external communication.
The following table lists the port numbers required by RSA Identity Governance and Lifecycle for internal and external communication:
 
PortFunction
21FTP connections. Can be used to transfer collection data.
22SSH connection port.
1158Oracle Enterprise Manager Express.
1555Oracle Listener for the AVDB data source.
8443Secure connection (using Secure Sockets Layer (SSL) and secure
   cookies) when you access RSA Identity Governance and
   Lifecycle. (default)
8444Secure communication between the RSA Identity Governance and
   Lifecycle application server and external components such as the
   remote agent and AFX.
Resolution

Configure firewall to open and redirect the ports


Note: This section describes the  firewall configuration procedure for Red Hat. The steps for firewall configuration for SUSE, are different.
  1. Log on to the appliance from the SSH console as the root user.
  2. Make sure iptables is enabled by executing the chkconfig command below.  This command will let you see if the iptables service is set to be on or off, based on runlevels. In the example below, the iptables service is off on all runlevels.
[root@server ~]# chkconfig --list iptables
iptables        0:off   1:off   2:off   3:off   4:off   5:off   6:off

  1. If the iptables service is off, we need to turn it on using the chkconfig command below:  In the example here, this will make the changes for runlevels 2, 3, 4 and 5.
[root@server ~]# chkconfig iptables on
iptables       0:off   1:off   2:on    3:on    4:on    5:on    6:off

  1. Backup the existing iptables file.
    1. Navigate to the directory below:
[root@server ~]# cd /etc/sysconfig/

  1. Take a backup of the iptables file, using the -p switch to preserve the specified attributes, such as default: mode, ownership, timestamps):
[root@server sysconfig]# cp -p iptables iptables_bk

  1. Open and edit the iptables file with a text editor, such as vi:
[root@server ~]# vi /etc/sysconfig/iptables

  1. Add the following lines, as in the example below, to the firewall section in iptables file to open the ports:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8444 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 1555 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 1158 -j ACCEPT
COMMIT

  1. Add a network address translation section, if you don’t have one, to perform port redirection from the standard https port. Note:  The NAT section typically appears before the *filter section.  If you already have a *nat section, add the two REDIRECT lines.  In this case, the *nat section is not there so it was added this way with two REDIRECT lines, just above the *filter section.
*nat
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
:OUTPUT ACCEPT
-A PREROUTING -i bond0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
-A PREROUTING -i bond0 -p tcp -m tcp --dport 444 -j REDIRECT --to-ports 8444
COMMIT

Note:  If there is no bonding, and if you are not using bonded interfaces, then bond0 needs to be replaced with the primary network interface,you are using.

  1. Save the file.  To exit from vi and save changes, press Esc then type :wq! to save and quit vi.
  2. Restart iptables with the command below.  Make sure iptables restarts without any error.
[root@server ~]# service iptables restart
iptables: Setting chains to policy ACCEPT: nat             [  OK  ]
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Unloading modules:                               [  OK  ]
iptables: Applying firewall rules:                         [  OK  ]

  1. Verify the rules were applied correctly by listing the iptables rules in the table view with the list command below:
[root@server ~]# iptables -L 
Chain INPUT (policy ACCEPT) 
target prot opt source destination 
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED 
ACCEPT icmp -- anywhere anywhere 
ACCEPT all -- anywhere anywhere 
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh 
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:pcsync-https 
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:pcsync-http 
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:livelan 
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:dbcontrol-oms 
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp 
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited 
Chain FORWARD (policy ACCEPT) 
target prot opt source destination 
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited 
Chain OUTPUT (policy ACCEPT) 
target prot opt source destination

  1. Verify that the /etc/sysconfig/iptables file looks similar to the following.  Use a cat command to view the file.
[root@server ~]# cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*nat
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
:OUTPUT ACCEPT
-A PREROUTING -i bond0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
-A PREROUTING -i bond0 -p tcp -m tcp --dport 444 -j REDIRECT --to-ports 8444
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8444 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 1555 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 1158 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

  1. Using the following URL:  https://<installation_machine_IP_address>, log on to RSA Identity Governance and Lifecycle from any compatible web browser and verify it is now accessible.  The RSA Identity Governance and Lifecycle login screen will appear.
  2. Enter the default credentials:
User:  AveksaAdm
Password:  aveksa123 

  1. When prompted, change the password for the AveksaAdmin user.
  2. Enter your new password in the New Password box.  Re-enter your new password in the Confirm Password box.  Click OK.  Valid passwords must consist of at least eight characters, one upper and one lower case character, and one number.
NotesYour server might have an existing file (that is, /etc/sysconfig/iptables) with some rules in it . Please take the backup of existing file, before editing new rules. For example, in this case we had an existing iptables file as in the example below (the number flag was set here to turn on line numbering):
[root@example.com ~]# cat /etc/sysconfig/iptables
      1 # Firewall configuration written by system-config-firewall
      2 # Manual customization of this file is not recommended.
      3 *filter
      4 :INPUT ACCEPT [0:0]
      5 :FORWARD ACCEPT [0:0]
      6 :OUTPUT ACCEPT [0:0]
      7 -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
      8 -A INPUT -p icmp -j ACCEPT
      9 -A INPUT -i lo -j ACCEPT
     10 -A INPUT -j REJECT --reject-with icmp-host-prohibited
     11 -A FORWARD -j REJECT --reject-with icmp-host-prohibited
     12 COMMIT

# We added the *nat  section before the *filter section, and new rules to open and redirect required TCP ports were added after line 9 that is between line 9 to 10.
# For more details please refer to the RSA Identity Governance and Lifecycle Installation Guide V7.0.1.  Information regarding firewall configuration for Red Hat on a soft appliance can be found on pages 182-184

Important support note:  There are other scenarios or reasons that can prevent Aveksa UI access.  Please refer to the troubleshooting section below, based on the failure results:

Unable to login into RSA Identity Governance and Lifecycle with secure HTTPS


Errors


The server.log file cites:
07/13/2012 16:22:11.516 INFO (main)
[org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-
0.0.0.0-8080
07/13/2012 16:22:11.557 ERROR (main)
[org.apache.coyote.http11.Http11Protocol] Error starting endpoint
java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)


Reason


The aveksa-standalone-full.xml file connection configuration has the wrong keystore password.

Solution


Edit the server.xml and correct the keystore information. 
 

Unable to login into RSA Identity Governance and Lifecycle with secure HTTPS


Errors


The server.log file cites:
2012-07-17 07:29:50,431 INFO [org.apache.coyote.http11.Http11Protocol]
Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
2012-07-17 07:29:50,560 ERROR [org.apache.coyote.http11.Http11Protocol]
Error initializing endpoint
java.io.IOException: Cannot recover key
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init
(JSSESocketFactory.java:394)
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket
(JSSESocketFactory.java:135)
at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:497)
at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
at org.apache.catalina.connector.Connector.initialize(Connector.java:1073)
at org.apache.catalina.core.StandardService.initialize
(StandardService.java:668)


Reason


The keystore password and server certificate passwords do not match.

Solution


Generate the keystore file with a server certificate with the same password. 

Attachments

    Outcomes