Brocade Webtools and Java

(Update on Mar/04/2015 BNA and Webtool certificate expiration at the bottom of this post)

(Update on Mar/19/2015 Followup on FOS level 6.x at the bottom of this post)

Since Oracle have tightened the screws on security they increased requirements on how these needs to be fulfilled.  With the introduction of Java JRE 1.7.0_40 some additional checks have been included to try and prevent Java hacks and block seemingly uncontrolled and insecure applets and JNLP files. First of all Oracle itself has set an expiration on the JRE version after which every time a pop-up screen will show to notify users to upgrade to the latest version. JRE 1.7.0_40 expired on the 10th of December 2013 and JRE 1.7.0_45 will expire on January 14h 2014. This is not because Oracle likes to beat the crap out of Administators (although I know a lot of them who would like to with an upgrade policy like this) but when viewing the extensive list of security patches they release (See here) I would be paranoid. You can disable this pop-up behaviour by adding the “deployment.expiration.check.enabled=false” in the “deployment.properties” file. I wouldn’t recommend this but hey, if yo have 40000 clients to maintain I can sympathise with your thoughts. Then there is the nasty habit of developers and vendors who do not sign their code or they use a self-signed certificate. This is as safe as leaving you wallet out in the open with your name an address on it and ask it to return if found. Not only will your wallet be emptied but very likely your home as well in the very near future. So in these situations where there is no trusted CA found who has signed your certificate with which you have signed your app the JRE will also show a pop-up box with warnings and will tell you about how doomed you are when you accept this app to run. The next level of protection is the type and strength of cryptography by which the certificate were created. With Java 1.7.0_40 Oracle started to restrict the hashing algorithm to MD5 and SHA. This means that mainly older certificates which still used MD2 are no longer able to run. The second restriction they imposed was the key-lenght of the cypher. Basically this means that certificates that were signed with keys of 2048 bit or smaller will also no longer be accepted. The (not preferred method) is to modify the “java.security” file and comment out the line

jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048

or remove the “RSA keysize <2048” part “So how does this fix my problem with not being able to run webtools and how do I fix this permanently?” you would ask. Well, very simple, Brocade has used a Class 3 VeriSign root certificate which was 1024 bits in length to sign their webtools java applets. These java apps are shipped with Brocade FOS (Fabric Operating System). Obviously you run into the above problem if you still run a FOS code which uses older or different root class certificates which have signed their own certs. Older code also may run either unsigned or self-signed code which will also be blocked if the deployment.properties and/or java.security is not adjusted.

Selection_059

Below a few examples:

I updated the JRE to 1.7.0_45 and connected to a 6510 running FOS 7.2.0a (I’ll update this one to 7.2.1 later to let you see the difference.)

Selection_060

Although there is still something missing in this FOS code level regarding the security descriptors in one or more JAR manifest files the JRE still allows you to run the application.

The console does show the issues in the different JAR files which are executed in succession.Selection_061

 As mentioned this 6510 is currently running FOS 7.2.0a and I’m able to fully manage the switch without any restrictions.Selection_062

When I connect to an older switch (in this case a 3850) running FOS 5.3.2c I get the below message:

Selection_063

The clue here is the failed certificate validation.

Selection_064

When you check the certificate details you’ll see the root certificate with which this applet was signed.

 Selection_065

The Symantec/VeriSign website will show you that this certificate was indeed signed with an 1024 bits key which is now prohibited.

Selection_066After I modified the security.properties file, restart the webbrowser and connect to the older switch once more you’ll see a different notification:

Selection_067

After acknowledging the tickbox and clicking on “Run” the webtools apps start to run.

Selection_069

The next question you might have is “Where the heck do I know what FOS version runs with which Java version”. The answer is even simpler then everything I explained before: “Release Notes”. Each release note shows the supported JRE.

Selection_070Selection_071So as promised, after I upgraded the switch to FOS 7.2.1 and reverted the change to the java.security file, the manifest messages have disappeared and the application will run without a problem.

Selection_072

As you see below it happily running 7.2.1 without a hitch.

Selection_073

So the message is simple. In addition to provide a high security environment for clients and java enabled web-apps make sure that you keep the JRE updated and check the release notes of FOS to check which java version is supported with that release.

I hope this was useful to you.

Regards,

Erwin

===== update ====

Brocade have a knowledge-base article around this problem with id SLN2448

Description

After upgrading Java on the client workstation, attempting to launch WebTools brings up a dialog reporting Application Blocked for Security and Failed to validate certificate. The application will not be executed. WebTools will subsequently fail to launch.

Resolution

 

Workaround: In both cases the downgrade to Java 7 release 21 and the Web Tools functioned properly. Workaround FOS: Java version issue with version 45 and 51 will be fixed in 7.2.1a, 7.2.0c and 7.1.1c.

Workaround BNA: Java 7 update 45 is supported in 12.0.4 and 12.1.4. and 12.1.5 =============== So in short upgrading to these version should resolve the issues seen lately. (among many other things :-))

===== Update 08-Aug-2014 ======

The FOS 7.3 has some updates when thing do not work and the release notes mention the following:

  1. When launching WebTools on a computer without Internet access, it could take up to 5 minutes to complete because the certificate revocation check performed for the WebTools application takes time to timeout. Users can turn off the certification revocation check on the Java control panel as a workaround.
  2. FOS v7.3.0 is qualified and supported with Oracle JRE 1.7.0 update 60. When launching Web tools directly using the browser for FOS 7.3.0, ensure that Oracle JRE update 1.7u60 is installed in that machine. WebTools can be launched from the local client of Brocade Network Advisor installed on Windows OS. Launching WebTools from local client of Brocade Network Advisor installed on Linux OS will fail due to the expiration check with JRE 1.7 update 51. As a workaround for this issue on Linux, please do the following changes in the Brocade Network Advisor installed computer.

1. Add following lines in <User Home>/.java/deployment/deployment.properties file
deployment.expiration.check.enabled=false
For example, if the user is root then the absolute path of this file is as below
/root/.java/deployment/deployment.properties
2. Launch the java control panel using below command and click on Ok button<Network Advisor Home>\jre\bin\jcontrol

  • In addition, users must check the “Enable Java content in the browser” box under the Security tab of Java Control Console to allow launching WebTools from BNA server clients.

March 4th update:

Some of you might have or will run into this depending on your JRE security settings (and when you read this). BNA and FOS both have their java code signed with a certificate that expires/expired on the 13th of March 2015. Every time you’ll open either of these you will run into a security message

brcd_cert_exp

Brocade fixes this in FOS 7.3.1a, 7.2.1e and BNA versioin 12.3.4. There seems to be no fix for any FOS 6.x release.

A workaround in the case you’re using Jave JRE 7 is to reduce the security setting from High to Medium. (I still wouldn’t recommend LOW). Java 8 does not provide such option and thus you’ll either have to live with these messages or upgrade FOS and BNA.

FOS 6.4.3g1 will have an updated certificate. So if you’re unable to use the workaround and are still stuck with a 4G platform switch which cannot run FOS 7.x than this is the release to resolve it.

Print Friendly, PDF & Email

Subscribe to our newsletter to receive updates on products, services and general information around Linux, Storage and Cybersecurity.

The Cybersecurity option is an OPT-OUT selection due to the importance of the category. Modify your choice if needed.

Select list(s):

26 responses on “Brocade Webtools and Java

  1. saiyed

    hi all, i have FOS 7.3.0c with brocade 6520 and i have tried all the mentioned settings & i am still having java issue, i have tried, JAVA 7.60, 7.71, 7.67 & 8.25 with errors such as “bad request details” i have opened a case with Brocade.
    More specific error below.
    Missing Application-Name manifest attribute for: http://192.xx.x3.xx/wt-app.jar
    log4j:WARN No appenders could be found for logger (com.brocade.wtcommon.access.AccessController).
    log4j:WARN Please initialize the log4j system properly.

    1. Erwin van Londen

      Hello Saied,

      According to the release notes the webtools app on FOS 7.3.0 should be compatible with JRE 1.7.0 U60. Have you tried to clear the JRE cache? I’ve seen these sorts of incompatibilties pretty often and in many cases being on the correct JRE level with the correct setting and a clear cache often resolves the issue.

      I’m curious what Brocade finds out. If you get any feedback from them please let me know.

      1. saiyed

        Update: issue is not resolved.

        1. reenabled the swtich after disable

        2. reran configure, please see the the output and advise if any thing should change.

        Fabric parameters (yes, y, no, n): [no] no
        Virtual Channel parameters (yes, y, no, n): [no] no
        F-Port login parameters (yes, y, no, n): [no] no
        D-Port Parameters (yes, y, no, n): [no] no
        RDP Polling Cycle(hours)[0 = Disable Polling]: (0..24) [0] 0
        Zoning Operation parameters (yes, y, no, n): [no] no
        RSCN Transmission Mode (yes, y, no, n): [no] no
        Arbitrated Loop parameters (yes, y, no, n): [no] no
        System services (yes, y, no, n): [no] yes

        Disable RLS probing (on, off): [on] on
        Portlog events enable (yes, y, no, n): [no] no
        ssl attributes (yes, y, no, n): [no] no
        rpcd attributes (yes, y, no, n): [no] no
        cfgload attributes (yes, y, no, n): [no] no
        webtools attributes (yes, y, no, n): [no] yes

        Basic User Enabled (yes, y, no, n): [no] no
        Perform License Checking and Warning (yes, y, no, n): [yes] yes
        Allow Fabric Event Collection (yes, y, no, n): [yes] yes
        Login Session Timeout (in secs): (60..432000) [7200]

        +++++++++++++++++++++++++++++++++++++++

        Found the following:

        Looks like the HTTP/HTTPS daemon in the switch had encountered errors and not pumping the data properly.

        As a workaround try to restart the switch http/https daemons this can be done by executing the following commands from CLI

        Procedure:
        execute “configure” from CLI
        select “http attributes”
        disable HTTP/HTTPS
        exit out of configure.
        execute “configure” and enable the HTTP/HTTPS services.

        PS: This just restarts the HTTP/S daemons and does not affect the switch functions in anyway.

        ++++++++
        Note: I did not find the same setting on FOS 7.3.0c and 6520
        may it has changed or burried in some other config.
        ++++++++++++++++++++++++++++++++++++++
        4. I changed the switchname to remove _ and keep it at simpler name just in case it was affecting java.
        +++++++++++++++++++++++++++++++++++++

      2. saiyed

        I have sucess finally without a lot of changes.
        1. Uninstalled all Java from my desktop
        2. Reboot
        3. connected to the switch without any java, it prompted for Java 6.25 ( Strange), i allowed it to download it, then relaunched the connection, broswer complained about out of data Java and asking for 1.7+ ( it should be noted that when connecting ie it downloaded 6.25 but firefox redirected me to update the java @ 8.31-current).
        I ignored and updated from my privious download to 7.60 ( supported by brocade for this switch).
        4. Reconnected to the swich, this time it complained about out of date but i said proceed, meanwhile browser add o n popp up were going on about the enable add on with some sort of SE add on ( SSV Helvper & SSV2 plugin helper), i allowed them.
        Then after the 1.7.60 install completed, the webtools loaded.
        Been fighting this for two days, i really wish Brocade & Java fix this type of issues its giving them bad name.
        Also i am not happy that Brocade does not allow access to thier KB support site, even thought i have mybrocade log in and we own several brocade product because we buy it from 3rd party-Not a good policy in my openion

        1. Erwin van Londen

          Hello Saiyed,

          Good to see it’s finally working. As you can imagine the issue is mainly with Java and Oracle’s release and security policies that seem to keep changing ever month. The java engine and plugins change in such a rapid pace it’s almost undoable to keep up-to-date with it. As you mentioned the Brocade app requests a certain level of the JRE but as soon the browser requests that version you first run into a browser check which flags that version as being insecure or incompatible (for whatever reason) and either blocks it entirely or it redirects you to Oracle’s Java webpage which, more or less, gives you no other option than to download and install the latest version.

          I always liked the webtools app but not for management purposes. I learned the CLI pretty quick and found that it’s not only much quicker but also more reliable adn your not depending on third party versions and related conflict you may run into.

          As for Brocade’s portal I cannot comment on that as I may have different privileges than you and I’m not in a position to make changes to their policies.

          Regards
          Erwin

  2. Adrian Alvarado

    Hi Erwin,

    Did you have tried or know how to make work brocade web tools from mac os X ?

    Regards

    1. Erwin van Londen

      Hello Adrian,

      I do not have access to a Mac so unfortunately I have to say No on your question. Apple nor Brocade has sponsored me one. 🙂

  3. vikranth

    Hi Erwin van Londen,
    Well, i have an issue regarding Brocade FOS logging into the IE. Java 7 u 67 blocks and issues a Failed Certificate.
    I tried all the stuff which has been talking around all the conversation held above by editing in Notepad++ and i cannot downgrade java as well due to environment standards, which should only run in JRE 7 u 67. But it doesn’t help me out.

    Is there any other solution with you that can help me out from this issue

    Thanks

    1. Erwin van Londen Post author

      Hello Vikranth,

      There have been some changes in both FOS and JRE. When you look at the release notes of FOS 7.3 in the “Webtools” section on page 47 it’ll show you additional options you can try. I’ll add this to this post as well.

      Still 1.7.0u67 is not on the supported JRE list even for FOS 7.3. The latest supported seems to be 1.7.0u60 but that should be close enough.

  4. jpm

    Hi Erwin,
    I had this annoying problem running and older FOS (6.4.2b) and a new java (1.7.0_55-b13) on my Windows 8.1 x64 laptop.
    The solution is as described (changing the line jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024 to jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 256) in the java.security file, however when running a 64bit system this file exists in TWO locations:
    c:\program files\java\jre7\lib\security
    c:\program files (x86)\java\jre7\lib\security
    Be sure to make the corrections in both files that worked for me 🙂
    /John

    1. Erwin van Londen Post author

      Hi John,

      Good tip. Thanks. I think it depends on which JRE you have installed on your system. I haven’t tested this but it could be that the 64-bit version can run in some sort of 32-bit compatibility mode which then uses some other config files and libraries.

      Cheers,
      Erwin

  5. jchiodo

    Dropping the value from ‘ <1024 ' to ' < 256 ', by itself, did not work for us here on a 48K at FOS 6.4.1b with Java 1.7.0_51 on the host. But doing that AND changing the java control panel security tab from HIGH to Medium did the trick nicely!

    1. Erwin van Londen Post author

      Hello J,

      Thanks for providing the info. Did you upgrade FOS afterwards on the 48K? I think the changing the security from High to Medium relieved the restriction of having no- or self-signed certificates. Not 100% sure that seems very often the case.

      Once again thanks for the tip.

      regards,
      Erwin

  6. javier

    Hello Erwin, I have got a brocade 6510 connect to a PC with SUSE linux.When I try connect to switch after that I write login and password the webtool dosn’t allow neither use the tool bar nor progress to other window.
    Linux suse has a java.security file but I don’t find “jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 1024" sentence.
    and then I can't apply it.
    Thanks,

    1. Erwin van Londen Post author

      Hello Javier,

      There are a couple of options. I don’t have a SUSE instance at my disposal right now but my Fedora system runs both the OpenJDK as well as the Oracle Java JRE.
      [1354][erwin@monster:~]$ locate java.security
      /usr/java/jre1.7.0_45/lib/security/java.security
      /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/jre/lib/security/java.security

      When looking at the Oracle “java.security” it shows on line 404:
      jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

      The same line is seen on the OpenJDK version. It may be that SUSE has packaged the RPM differently so the locations might not be the same.

      You did not mention the FOS version running on the switch. Maybe its not supported for that particular JRE version. I know Brocade have put some extra restrictions in later release notes stating that the 1.7.0_45 JRE is not supported and I do think they don't support the OpenJDK at all.

      Hope this helps a bit.

      Cheers,
      Erwin

      1. javier

        Thanks Erwin for you help, We think the problem is the java version of mozilla explorer. It’s a linux suse version 1.6.0. (IBM developed kit for linux) The switch has a 7.2.0a OS version.

        However We can connect to switch with the same version 1.6.0 in a windows PC.
        To sum up, the problem is in Linux java version but We don’t know why.
        Regards
        Javier

        1. Erwin van Londen Post author

          Hello Javier,

          It’s a bit hard to troubleshoot why it doesn’t work. There can be many reasons. I’ve found that when your able to get a JRE console running it might give you an idea either where it stops or what causes the issue. To be honest I’ve often used a trial and error method to dig through some of these issues. I also must confess that I haven’t used the Brocade webtools for a long time. The CLI has always worked better and faster for me.

          Cheers,
          Erwin

  7. rlewin

    I am having the exact same problem that brjaiswal has. I’ve also tried the same things with the same results. In other words, I am not able to run the switch explorer after the install of java 7 update 51.

  8. keivan_mh

    THANKSSSSS – I don’t know how to thank you, I couldn’t find a solution almost anywhere on the net, this worked for me straight away.

    Just a hint that Windows users need to modify that “java.security” using Notepad++ or similar app. Normal Notepad will NOT work.

    1. Erwin van Londen Post author

      Thanks Keivan, glad it worked for you. Yes, notepad++, UltraEdit or VI would be the best options to modify any sort of text document. These do know about the intricacies between the cr/lf handling between posix and non-posix systems.

  9. saiyed

    I have tried all the tricks listed here and still i cannot get both versions of java to operate on my laptop.
    I need Java 6 & 7, i have updated/downgrated to 7.25 without any luck, the newer swtiches work with Java 7 ( Brocade 7800)
    but the older one with FOS 6.* 5300,300 dont.

    1. Erwin van Londen Post author

      Yes, I know it’s a really annoying issue especially if you have different FOS code versions spread across your fabric. To be fairly honest, I’ve never been a huge fan of the webtools feature and Brocade could have done better without it. The CLI is much more powerful. FOS itself would have become more stable as well but hey, I’m no paying customer. 🙂

  10. brjaiswal

    Hi Erwin,

    I have changed RSA keySize < 1024 to 256 but I am still not able to access brocade 5300 web tools. I have v7.2.0b on switch and java 7 update 51 in my laptop. I also tried to comment out "jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 1024" but not working. Please suggest any solution.

    Thanks

    1. Erwin van Londen Post author

      Hello,

      When I look at the release notes this FOS version only supports JRE 1.7.0_25.

      WebTools Compatibility
      FOS v7.2 is qualified and supported only with Oracle JRE 1.7.0 update 25.

      If you downgrade your JRE it is likely to work.

      Regards Erwin

  11. AlexeiStepanov

    at the same time, our storage tools require no more than 1.7.40… what a mess!

    1. Erwin van Londen Post author

      Hello Alexey,

      You can install more then one JRE on a system. It is then up to the java applet to discover the correct version and use this accordingly. Not 100% sure if either Brocade, HDS, HP, IBM, Cisco etc…. use this accrosss their software portfolio.