(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.
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.)
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.
When I connect to an older switch (in this case a 3850) running FOS 5.3.2c I get the below message:
The clue here is the failed certificate validation.
When you check the certificate details you’ll see the root certificate with which this applet was signed.
The Symantec/VeriSign website will show you that this certificate was indeed signed with an 1024 bits key which is now prohibited.
After acknowledging the tickbox and clicking on “Run” the webtools apps start to run.
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.
As you see below it happily running 7.2.1 without a hitch.
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.
===== update ====
Brocade have a knowledge-base article around this problem with id SLN2448
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.
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:
- 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.
- 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
For example, if the user is root then the absolute path of this file is as below
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
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.