Clarity

Expand all | Collapse all

Open Work bench SSL issues

  • 1.  Open Work bench SSL issues

    Posted 09-11-2018 06:16 AM

    Hi,

     

    Recently we upgraded Clarity 15.3 and updated to SSL. now the url is https://Clarity-uat:8443. I've updated the scheduler url with the same.

     

    When I access from my desktop, it works. But when they access from other system(different site), it fails with error
    "A Server error occurred during Login: - Received fatal alert: protocol_version"

     

     

    When I clicked the Setup button, both the settings are similar(my system & other). Could you please confirm what would be difference in settings or is there any prerequisite I need to check ?

     

    I compared the following with working and non working environment

    1) Control Panel--> JAVA --> Advanced Tab In Advanced Security settings, Use TLS 1.1 and Use TLS 1.2 was missing. So I added them

    2) Java_Home and Path variable has been updated to JRE.(Please confirm should it be JRE or JDK)

    3) Compared the browser(IE 11) Internet Options settings. it matches.

     

    Restarted the system and it still we are getting the same error.

     

    I tried following the communities link(https://communities.ca.com/thread/241777584-javaxnetsslsslexception-received-fatal-alert-protocolversion-when-executing-a-step-that-tries-to-run-on-a-secure-environment), it says abt vmoptions. How do I add it?

     

    I also tried enabling the logs for OWB using TEC document (https://communities.ca.com/docs/DOC-100647536) but it only works for my system. For others, it didn't even show any logs

     

    Please do advise ASAP, as I need to push to production very soon

     

     

     

     

     

    Thanks

     

    Sreeram



  • 2.  Re: Open Work bench SSL issues

    Posted 09-11-2018 09:54 PM

    Does the JRE installed on client machine should be same inside the Schedule connect



  • 3.  Re: Open Work bench SSL issues

    Posted 09-12-2018 01:11 AM

    Hi Shoichi,

     

    thanks for your reply. When I compared the working and non -working environment, these are the result

     

    JRE version inside Schedule connect

    Working Env: JRE7(folder)

    Non-working Env: JRE7(folder)

     

    JRE in the client desktop

     

    Working env: 1.8.0_152

    non-working env: 1.8.0_60

     

    net.properties (in lib folder)in schedule connect for both working and non-working env doesn't have the tunneling property. Please find below

    <

    ############################################################
    #   Default Networking Configuration File
    #
    # This file may contain default values for the networking system properties.
    # These values are only used when the system properties are not specified
    # on the command line or set programatically.
    # For now, only the various proxy settings can be configured here.
    ############################################################

    # Whether or not the DefaultProxySelector will default to System Proxy
    # settings when they do exist.
    # Set it to 'true' to enable this feature and check for platform
    # specific proxy settings
    # Note that the system properties that do explicitely set proxies
    # (like http.proxyHost) do take precedence over the system settings
    # even if java.net.useSystemProxies is set to true.
     
    java.net.useSystemProxies=false

    #------------------------------------------------------------------------
    # Proxy configuration for the various protocol handlers.
    # DO NOT uncomment these lines if you have set java.net.useSystemProxies
    # to true as the protocol specific properties will take precedence over
    # system settings.
    #------------------------------------------------------------------------

    # HTTP Proxy settings. proxyHost is the name of the proxy server
    # (e.g. proxy.mydomain.com), proxyPort is the port number to use (default
    # value is 80) and nonProxyHosts is a '|' separated list of hostnames which
    # should be accessed directly, ignoring the proxy server (default value is
    # localhost & 127.0.0.1).
    #
    # http.proxyHost=
    # http.proxyPort=80
    http.nonProxyHosts=localhost|127.*|[::1]
    #
    # HTTPS Proxy Settings. proxyHost is the name of the proxy server
    # (e.g. proxy.mydomain.com), proxyPort is the port number to use (default
    # value is 443). The HTTPS protocol handlers uses the http nonProxyHosts list.
    #
    # https.proxyHost=
    # https.proxyPort=443
    #
    # FTP Proxy settings. proxyHost is the name of the proxy server
    # (e.g. proxy.mydomain.com), proxyPort is the port number to use (default
    # value is 80) and nonProxyHosts is a '|' separated list of hostnames which
    # should be accessed directly, ignoring the proxy server (default value is
    # localhost & 127.0.0.1).
    #
    # ftp.proxyHost=
    # ftp.proxyPort=80
    ftp.nonProxyHosts=localhost|127.*|[::1]
    #
    # Gopher Proxy settings. proxyHost is the name of the proxy server
    # (e.g. proxy.mydomain.com), proxyPort is the port number to use (default
    # value is 80)
    #
    # gopher.proxyHost=
    # gopher.proxyPort=80
    #
    # Socks proxy settings. socksProxyHost is the name of the proxy server
    # (e.g. socks.domain.com), socksProxyPort is the port number to use
    # (default value is 1080)
    #
    # socksProxyHost=
    # socksProxyPort=1080
    #
    # HTTP Keep Alive settings. remainingData is the maximum amount of data
    # in kilobytes that will be cleaned off the underlying socket so that it
    # can be reused (default value is 512K), queuedConnections is the maximum
    # number of Keep Alive connections to be on the queue for clean up (default
    # value is 10).
    # http.KeepAlive.remainingData=512
    # http.KeepAlive.queuedConnections=10

    >

    Strangely in working env, JRE in client desktop has "jdk.http.auth.tunneling.disabledSchemes=Basic" but in non-working it doesn't have the that line

     

    Please advise.



  • 4.  Re: Open Work bench SSL issues

    Broadcom Employee
    Posted 09-12-2018 07:09 AM

    Hi Sreeram,

     

    When you download owb from Account Settings you'll get these versions for ppm 15.3:

    java version "1.8.0_181"  (under Schedule connect folder)

    The owb version should show: 2.1.2 (15.3.0.200 05 17) 

     

     I see you mentioned to have a folder called JRE7 under schedule connect, this seems then to be an older owb version.

    Please start with a fresh owb installation and troubleshoot from there.

     

    Regards,

    Eric.

     



  • 5.  Re: Open Work bench SSL issues

    Broadcom Employee
    Posted 09-11-2018 08:44 PM

    Hi Sreeram,

     

    After JRE1.8.0_111-b14, Basic authentication for HTTPS tunneling is disabled by default.

    So, if you use later JRE version than JRE1.8.0_111-b14, your proxy may encounter authentication issue.

     

    Please check "Disable Basic authentication for HTTPS tunneling" section in below document.

    Java™ SE Development Kit 8, Update 111 Release Notes 

     

    Regards,

    Shoichi



  • 6.  Re: Open Work bench SSL issues

    Posted 09-11-2018 12:21 PM

    Just wondering about the basics...

    Do you have the same version of OBS and schedule connect on both?



  • 7.  Re: Open Work bench SSL issues

    Broadcom Employee
    Posted 09-12-2018 12:53 AM

    Hi Sreeram,

     

    I think Open Workbench uses JRE inside the Schedule connect.

     

    Could you check JRE version which is inside the Schedule connect?

    And check jdk.http.auth.proxying.disabledSchemes parameter in net.properties file which is placed in <JRE> of Schedule connect.

     

    Regards,

    Shoichi



  • 8.  Re: Open Work bench SSL issues

    Broadcom Employee
    Posted 09-12-2018 05:18 AM

    Hi Sreeram,

     

    It is strange result.

     

    My understanding, "jdk.http.auth.tunneling.disabledSchemes=Basic" line in net.properties is added since JRE1.8.0_111-b14.

    Did anyone delete the line of net.properties on 1.8.0_152?

    BTW, this line maybe added by using system environment parameter or java options.

    Could you check them?

     

    Regards,

    Shoichi

     



  • 9.  Re: Open Work bench SSL issues

    Posted 09-11-2018 11:01 PM

    Hi

     

    If we go down to JRE7, will it work?



  • 10.  Re: Open Work bench SSL issues

    Posted 09-11-2018 09:35 PM

    Thanks Shoichi. But how to disable it. 

     

    Sreeram



  • 11.  Re: Open Work bench SSL issues

    Posted 09-11-2018 01:05 PM

    Yes its the same. OWB and schedule connect r same version. Is Jdk prequisite for owb https setup? 



  • 12.  Re: Open Work bench SSL issues

    Posted 09-11-2018 11:37 PM

    @shoichi I just checked the system with JRE7, it still throws the same error. If the tunneling issue exists in both 1.7 and 1.8, then how and where to update the tunneling issue.



  • 13.  Re: Open Work bench SSL issues

    Broadcom Employee
    Posted 09-11-2018 11:44 PM

    Hi Sreeram,

     

    Open Workbench may check JRE version, so it will not work with JRE7.

     

    If possible, try to use older version than 1.8.0_111-b14.

     

    Or check <Your JRE HOME>\lib\net.properties file and you will find below lines.

     

    -----------

    #jdk.http.auth.proxying.disabledSchemes=
    jdk.http.auth.tunneling.disabledSchemes=Basic

    ------------

     

    Try to comment out like as below. 

    -----------

    #jdk.http.auth.proxying.disabledSchemes=
    #jdk.http.auth.tunneling.disabledSchemes=Basic

    ------------

     

    Regards,

    Shoichi



  • 14.  Re: Open Work bench SSL issues

    Posted 09-11-2018 01:32 PM

    OWB needs only jre and schedule connect comes with a supported version of jre for OWB use.