I have a weblogic 10.3.6 installed in windows server 2008 R2 64-bit with Java 7 update 111. With in weblogic server I have 4 manged server running many java applications.
I have new client web-services application need to be deployed in one of the 4 manged server and this application require TLS1.2 as requested by third party services provider application. For that purpose, I am setting the following property in client application code like System.setProperty("jdk.tls.client.protocols", "TLSv1.2");
Question:
Will the statement System.setProperty("jdk.tls.client.protocols", "TLSv1.2"); change the protocol for only manged server where the application is deployed ? Or it will be for all application servers available within weblogic ?
If this command change the protocol for all manged servers, then this is a problem since other applications may get affected. What is the solution in this case and what is the right action to be taken to enable the required SSL protocol for that specific application without affecting other running applications ?
It should affect all managed servers on that box (probably after the nodes are restarted)
TLS is compatible with SSL - just not with insecure handshake protocols (which you should have stopped doing years ago) For more information, see: Modifiying Weblogic Server to use TLS
Related
OpenShift swiftly addressed the SSL 'Poodle' vulnerability around October 16th 2014. Since then the e-commerce provider I work with can no longer establish a secure HTTPS connection with my OpenShift PHP application. I suspect this is, at least in part, because SSL3 is no longer an available protocol.
The error logged at the e-commerce provider end is:
javax.net.ssl.SSLException
java.lang.RuntimeException: Could not generate DH keypair
Here's what I've tried and discovered so far:
The online SSL testing tool at https://www.ssllabs.com/ssltest/ indicates my SSL Certificate is installed correctly (installed via the OpenShift WebConsole), and it receives an 'A' grade. HTTPS works fine when connecting to my OpenShift PHP application in a normal web browser. In general the SSL Certificate & installation itself seems fine.
As a test, I have tried using OpenShift's shared SSL Certificate instead of my own, with exactly the same result.
Java 7
The remote e-commerce platform that is attempting to connect to my OpenShift PHP app via HTTPS uses Java 7. Tech support thinks the issue is that their Java 7 system doesn't support cipher key lengths > 1024 bits. Unfortunately they're not in a position to upgrade their system to Java 8 at present, so their hands are a bit tied.
Handshake Simulation
The ssllabs analysis of my SSL Certficate includes a useful Handshake Simulation test with various clients. This actually shows a Java 7 simulation connecting OK using TLS1.0, however the Java 6 simulation fails with a 'Client does not support DH parameters > 1024 bits' error - roughly echoing what e-commerce tech support is seeing reported by their Java 7 based system.
How might I solve this? To narrow the question down a little:
Is there a simple adjustment my e-commerce provider could make at their end to enable HTTPS connections to OpenShift applications, without them having to upgrade Java or make significant changes that could impact others? e.g. An option to accept DH parameters > 1024 bits.
Is there anything I can adjust at my end (perhaps an OpenShift or PHP setting) to enable their Java 7 based system to establish a HTTPS connection with my OpenShift application successfully? e.g. An option instructing OpenShift to provide DH parameters <= 1024 bits.
Restarting your application should resolve the issue as it will pick up the latest JDK that should contain the latest fixes for this issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1035818
https://bugzilla.redhat.com/show_bug.cgi?id=1080125
I have an Application Client deployed on a local Glassfish 4.1 with Java 8u20 installed. Now whenever I try to start the client on the localhost (same machine) using Java Web Start it gets blocked by Java Security with the message:
Location: http://localhost:8080
Reason: The Java security settings have prevented this application from running. You may change this behavior in the Java Control Panel.
I added localhost to the Exception Site List with following entries:
file:///
http://localhost
http://127.0.0.1
http://localhost.localdomain
then I even imported the Glassfish self-signed certificate as a Trusted Certificate in the Java Control Panel. Finally I enabled Mixed code and disabled certificate revocation checks in the Control panel. But still my application gets blocked.
As the medium Security level is not available anymore, what can I do further?
If you use a javaws from a java 1.7 u25 or earlier, your application client will work.
I have the same problem with Java8u31. My application client won't start with a javaws later than u25, but if is use u25 or under it will.
So, I use u25 to start the application client, but the application runs in the java 1.8 u31 environment.
I also cannot get the exception site list to work. I starting to think their is a bug in java here.
I tried to replace the s1as certificate in glassfish per these instructions to no avail. https://blogs.oracle.com/quinn/entry/glassfish_java_web_start_and
Not sure that it is possible to have glassfish automatically sign an application client with the new security restrictions!
As you can see, there's the new instructions:
https://docs.jboss.org/author/display/AS71/JMX+subsystem+configuration
And the old RMI instructions:
https://docs.jboss.org/author/pages/viewpage.action?pageId=21627109
I can get the new instructions working, but we use nagios, which only allows checking JMX via RMI, so I need to get RMI JMX working.
Does anyone have a solution for this?
I can't use the old instructions because it says <jmx-connector> is no longer supported.
I've added the following to my JAVA_OPTS on JBoss startup:
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false" -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl -Djava.rmi.server.hostname=10.20.2.50
but i can't get jconsole to connect to service:jmx:rmi:///jndi/rmi://10.20.2.50:12345/jmxrmi
(PS. If anyone with redhat paywall access could report back on the answer here: https://access.redhat.com/solutions/263763 that would be swell :P)
To connect to JMX the URL entered should be in the format
service:jmx:remoting-jmx://{host_name}:{port}
Standalone mode
where {port} is the native management interface of the AS7 installation being monitored (default=9999).
Domain mode
where {port} is the JMX subsystem interface of the AS7 installation being monitored (first server=4447, port-offset=150 next server).
<subsystem xmlns="urn:jboss:domain:jmx:1.1">
<show-model value="true"/>
<remoting-connector use-management-endpoint="false"/>
</subsystem>
Both modes
Outside localhost you have to set -Djboss.bind.address.management or inside xml (standalone.xml / host.xml).
Once connected the capabilities provided by jconsole can be used as normal.
Authentication
The connector is making use of JBoss Remoting to communicate with the server, for this reason the exact same authentication mechanisms as are used by the CLI will apply here.
Local
For processes running local to the AS7 installation we support a local authentication mechanism which allows clients to verify their identity by sharing a token on the filesystem with the server - this mechanism runs silently without any further user interaction required.
Username / Password
Where local authentication is not possible such as if the client is running as a different user than the AS7 process or is running on a remote installation by default the next mechanism to be used is username / password based. Where this mechanism is used the username and password of a user in the ManagementRealm if using the default management connector (port 9999) or in the ApplicationRealm if using the remoting connector (port 4447) should be supplied in the boxes on the 'New Connection' screen before the 'Connect' button is clicked.
The $JBOSS_HOME/bin/add-user.sh (Linux) or $JBOSS_HOME/bin/add-user.bat (Windows) scripts can be used to add these users. Make sure to choose between Management User and ManagementRealm vs Application User and ApplicationRealm depending on whether you're using the default management connector or the remoting connector (usually used with domain mode or when connecting remotely).
Necessary libraries to connect JMX over JBoss Remoting
The JMX MBeanServer is accessible using JBoss Remoting through the management connection. Therefore, it is necessary to add the following libaries from the modules directory of the EAP6 / AS7 distribution to the classpath of the monitoring application:
org/jboss/remoting3/remoting-jmx
org/jboss/remoting3
org/jboss/logging
org/jboss/xnio
org/jboss/xnio/nio
org/jboss/sasl
org/jboss/marshalling
org/jboss/marshalling/river
Ref: Using jconsole to connect to JMX on AS7
Other resource: Connecting VisualVM with a remote JBoss AS 7 / EAP6 JVM process
EDIT:
JBoss EAP 5 supports JMX monitoring using RMI, where JBoss EAP 6 does not. EAP 6 uses “remoting-jmx” instead of “rmi”.
You should look for another solution, as SNMP, or proper plugin for nagios
See:
JVM monitoring via SNMP of JBoss EAP 6 worker nodes with pnp4nagios Template
Jboss SAR MBean and Perl plug-in for Nagios compatible with Jboss 7.1.1
My apllication is deployed on Tomcat 6 with Java 6, I want to restrict the SSL protocol to use only TLSv1.1. According to Java 6 documentation JCE isn't supporting TLSv1.1 while Java 7 does.
Upgrade my Java version isn't acceptable. There is any providers that implements TLSv1.1 protocol that I can integrate to my java?
Since it's production system I am looking for quick and safe fix. I thought to front end my application server with apache web server at the same host(which supports TLSv1.1 through openssl) and use him as a proxy server. Unfortunately my physical resources are low.
Any other ideas are welcome.
Thanks.
Front it with a system that does the SSL and does get security updates. You can run apache using the connector - if you still trust this - or setup a Java application (a newer version of Tomcat?) to act as an SSL proxy (connecting to port 80 of your server, if this is acceptable to you).
I've having a slight problem and i'll like you so share you opinion experience on it.I've deployed a jasperserver on tomcat 6 in a environment where anything has to pass through the proxy server to have access to the internet.
i'm wondering about where to put the proxy params and credentials. at tomcat level or at jasperserver level ?I've seen that JavaMail does support retrieving or sending mail through proxy server.Another thing is that i've also seen that all Java Tcp can be configured using the Java Runtime to direct socket connection to the proxy server which can harm performance.
What other options do i have?
thanks for reading this!