Unable to connect to Clarity via IP when using HTTPS

Document ID : KB000020757
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

A server can be addressed on the following three ways:

With its host name e.g. "clarity-server"
With the host name and the domain e.g. "clarity-server.ca.com"
With its IP address e.g. "123.123.123.123"

In Clarity v13.x you can use all three methods to connect to Clarity, when SSL is not enabled.
As soon as you enable SSL, only the URL given in the "HTTPS Entry URL" field in CSA works. The two others will show the login screen, but the login will hang. In app-system.log you will find an error message that loops and generates thousands of identical lines.
This can be reproduced with Clarity 13.0.1 fix pack 6 and Clarity 13.1.0 fix pack 4. In Clarity 12.1.3 the issue could not be reproduced and the system behaves as expected.

Steps to Reproduce:


  1. Configure an out-of-the-box Clarity v13.x in CSA

    1. a. disable HTTP connections
    2. b. enable HTTPS connections
    3. c. enter the "HTTPS Entry URL" like https://hostname:8043


  2. Restart the application service (app)
  3. Login from any supported browser with the URL https://hostname:8043
  4. If the login is successful, logout
  5. Identify the IP address of the host running Clarity
  6. Login from any supported browser with the URL https://ip address>:8043

Expected Result: Successful Login in a reasonable amount of time
Actual Result: Login hangs, app-system.log will be filled with a loop in the stack trace

LOG FILE EXAMPLE:


2013/02/06 19:43:13.290 | SEVERE: Servlet.service() for servlet UIServlet threw exception 
2013/02/06 19:43:13.290 | java.lang.StackOverflowError 
2013/02/06 19:43:13.290 | at java.util.Stack.empty(Stack.java:96) 
2013/02/06 19:43:13.290 | at sun.misc.URLClassPath.getLoader(URLClassPath.java:283) 
2013/02/06 19:43:13.290 | at sun.misc.URLClassPath.getResource(URLClassPath.java:168) 
2013/02/06 19:43:13.290 | at java.net.URLClassLoader$1.run(URLClassLoader.java:194) 
2013/02/06 19:43:13.290 | at java.security.AccessController.doPrivileged(Native Method) 
2013/02/06 19:43:13.290 | at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 
2013/02/06 19:43:13.290 | at sun.misc.Launcher$ExtClassLoader.findClass(Launcher.java:229) 
2013/02/06 19:43:13.290 | at java.lang.ClassLoader.loadClass(ClassLoader.java:306) 
2013/02/06 19:43:13.290 | at java.lang.ClassLoader.loadClass(ClassLoader.java:295) 
2013/02/06 19:43:13.290 | at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) 
2013/02/06 19:43:13.290 | at java.lang.ClassLoader.loadClass(ClassLoader.java:295) 
2013/02/06 19:43:13.290 | at java.lang.ClassLoader.loadClass(ClassLoader.java:247) 
2013/02/06 19:43:13.290 | at java.lang.Class.forName0(Native Method) 
2013/02/06 19:43:13.290 | at java.lang.Class.forName(Class.java:169) 
2013/02/06 19:43:13.290 | at com.ca.clarity.jdbc.sqlserverbase.ddv.c(Unknown Source) 
2013/02/06 19:43:13.290 | at com.ca.clarity.jdbc.sqlserverbase.BaseDriver.connect(Unknown Source) 
2013/02/06 19:43:13.290 | at java.sql.DriverManager.getConnection(DriverManager.java:582) 
2013/02/06 19:43:13.290 | at java.sql.DriverManager.getConnection(DriverManager.java:154) 
2013/02/06 19:43:13.290 | at com.niku.union.persistence.connection.ProxoolContext.getConnection(ProxoolContext.java:153) 
2013/02/06 19:43:13.290 | at com.niku.union.persistence.PersistenceController.createLocalContext(PersistenceController.java:432) 
2013/02/06 19:43:13.290 | at com.niku.union.persistence.PersistenceController.doProcessRequest(PersistenceController.java:540) 
2013/02/06 19:43:13.290 | at com.niku.union.persistence.PersistenceController.processRequest(PersistenceController.java:289) 
2013/02/06 19:43:13.290 | at com.niku.union.web.WebRegistry.executeStatement(WebRegistry.java:89) 
2013/02/06 19:43:13.290 | at com.niku.union.web.WebRegistry.getActionFromDatabase(WebRegistry.java:188) 
2013/02/06 19:43:13.290 | at com.niku.union.web.WebRegistry.getAction(WebRegistry.java:119) 
2013/02/06 19:43:13.290 | at com.niku.union.web.cache.ActionCache.getFromPersistence0(ActionCache.java:164) 
2013/02/06 19:43:13.290 | at com.niku.union.web.cache.ActionCache.getFromPersistence(ActionCache.java:99) 
2013/02/06 19:43:13.290 | at com.niku.union.utility.caching.LazyCache.get(LazyCache.java:69) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.refreshClientAction(VXMLService.java:503) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.processRequest(VXMLService.java:445) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.processRequest(VXMLService.java:445) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.processRequest(VXMLService.java:445) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.processRequest(VXMLService.java:445) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.processRequest(VXMLService.java:445) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.processRequest(VXMLService.java:445) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.processRequest(VXMLService.java:445) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.processRequest(VXMLService.java:445) 
2013/02/06 19:43:13.290 | at com.ca.clarity.uif.service.vxml.VXMLService.processRequest(VXMLService.java:445)

Solution:

WORKAROUND:
Instead of encrypting SSL in Clarity (either in Tomcat, WebSphere or WebLogic), offload the SSL handling to a front end device (i.e. hardware load balancer or Apache HTTP Server), then run Clarity without SSL ports enabled. Set the SSL Settings in Clarity to "SSL is used but processed externally".
This problem is not reproducible if Clarity itself is not encrypting the SSL traffic.

STATUS/RESOLUTION:
Resolved in Clarity 13.0.1 Generic Patch. Reference TEC572268

Keywords: CLARITYKB, CLRT-70954, CLRT-68836, clarity13resolved.