Have a JDK7 app running on Tomcat and it does have the following env settings:
-Dhttps.protocols=TLSv1.1,TLSv1.2
The above setting ensures that we don't use TLS 1.0 when connecting over HTTPS while making API calls etc.
We also use the org.springframework.mail.javamail.JavaMailSenderImpl class to send outgoing SMTP email, and use these props:
mail.smtp.auth=false;mail.smtp.socketFactory.port=2525;mail.smtp.socketFactory.fallback=true;mail.smtp.starttls.enable=true
The problem is that the connection to the SMTP email server is failing when it's upgraded to TLS1.2.
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake
Is there a settings or code change that will force the TLS1.2 protocol?
I did some searching and it looks like these env settings are only for applet and web clients, not for server side apps
-Ddeployment.security.SSLv2Hello=false -Ddeployment.security.SSLv3=false -Ddeployment.security.TLSv1=false
This is the fix for the next guy looking:
mail.smtp.starttls.enable=true;
mail.smtp.ssl.protocols=TLSv1.2;
It didn't work for me in one pretty old app and I couldn't realize why. After some research I found that the javax.mail version in the app dependencies was 1.4. You must upgrade to at least 1.5.
I needed both Vojtech Zavrel and Sunny's answer in my case. I was running Java 1.8 Spring Boot 1.2.5 and running on Big Sur 11.2.3 and spring version 4.2.1.RELEASE.
After I updated my dependency like this
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.5.0-b01</version>
</dependency>
and I updated my JavaMailSenderImpl with
Properties prop = new Properties();
prop.setProperty("mail.smtp.auth", "true");
prop.setProperty("mail.smtp.starttls.enable", "true");
prop.setProperty("mail.smtp.ssl.protocols", "TLSv1.2"); // Added this line
prop.setProperty("mail.smtp.ssl.trust", mailUri.getHost());
mailSender.setJavaMailProperties(prop);
I saw the Received fatal alert: protocol_version error resolve.
An update to the most recent version (1.6.2.) of Java Mail also fixes the issue. In my case I upgraded from:
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.5.0-b01</version>
</dependency>
to:
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>javax.mail</artifactId>
<version>1.6.2</version>
</dependency>
This fixed the error
javax.mail.AuthenticationFailedException: 421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2
I was getting from an Outlook SMTP-Server. No property changes needed.
Related
I am trying to access mapr path remotely, using a spring boot application. I have set the fs.mapr.bailout.on.library.mismatch property to false, to avoid the error on version mismatch. Still whenever the getFileStatus() function gets called, the application stops with the following error:
2020-12-15 10:07:18,7377 ERROR JniCommon fs/client/fileclient/cc/jni_MapRClient.cc:691 Thread: 123145425235968 Mismatch found for java and native libraries java build version 6.0.1.20180404222005.GA, native build version 6.0.1.20190808152212.GA java patch vserion $Id: mapr-version: 6.0.1.20180404222005.GA 1aeeb6d3c17c777fcba0, native patch version $Id: mapr-version: 6.0.1.20190808152212.GA 1aeeb6d3c17c777fcba0
2020-12-15 10:07:18,7378 ERROR JniCommon fs/client/fileclient/cc/jni_MapRClient.cc:708 Thread: 123145425235968 Client initialization failed.
Code:
FileSystem fileSystem = FileSystem.newInstance(new Configuration());
Configuration conf = fileSystem.getConf();
conf.set("fs.mapr.bailout.on.library.mismatch", "false");
Path OffsetPath = new Path(filePath);
FileStatus file = fileSystem.getFileStatus(filePath); ====> This statement gives error
hbase dependencies used:
<dependency>
<groupId>com.mapr.fs</groupId>
<artifactId>mapr-hbase</artifactId>
<version>6.0.1-mapr</version>
</dependency>
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-client</artifactId>
<version>1.1.8-mapr-1710</version>
</dependency>
How can I correct this?
So it isn't a great idea to just disable the version mismatch error. Some mismatch is OK for some tasks, but some mismatch can be fatal.
To say much more, it would be helpful to have a little bit of clarification.
when you say remote access, are you talking from one cluster to another? Or from a client machine that is outside the cluster?
assuming that you mean the second case (client outside the cluster), what did you install on the client machine?
why did you disable the version mismatch? What versions are you worried will not match?
does the POSIX interface or the local loopback NFS work from the problem node?
does the hadoop shell work from the problem node?
I have been using EWS(Exchange Web Service) for reading emails from a shared email box in Java 8.
After upgrading to Java 11 (Open JDK 11/Zulu Java 11), facing exceptions while reading emails.
This is the Exception:
java.lang.NoClassDefFoundError: javax/xml/ws/http/HTTPException at
Microsoft.exchange.webservices.data.core.ExchangeService.internalFindFolders(ExchangeService.java:370)
~[ews-java-api-2.0.jar:na]
Adding the below dependency in your pom.xml will help in reading emails from a shared mailbox.
<dependency>
<groupId>javax.xml.ws</groupId>
<artifactId>jaxws-api</artifactId>
<version>2.2.1</version>
</dependency>
I'm trying to use OpenSSL engine on an HTTP server.
My configuration looks like
HttpServerOptions options = new HttpServerOptions()
.setSsl(config.getSsl())
.setSslEngineOptions(new OpenSSLEngineOptions())
.setClientAuth(ClientAuth.REQUEST)
.setKeyStoreOptions(keystoreOptions)
.setTrustStoreOptions(truststoreOptions)
.setEnabledSecureTransportProtocols(enabledSecureTransportProtocols);
I'm using Vert.x 3.6.2, which brings Netty dependencies 4.1.30. I also added to my pom:
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-tcnative</artifactId>
<version>2.0.20.Final</version>
<classifier>linux-x86_64-fedora</classifier>
</dependency>
Because my HTTP server is deployed on RHEL 7 with OpenSSL 1.0.1 (I know it's old). I'm getting the following error:
io.vertx.core.VertxException: OpenSSL is not available
And as I can see from logs, netty handler try to load this native library netty-tcnative and can't find it in the classpath:
netty-tcnative not in the classpath; OpenSslEngine will be unavailable. I don't know how to resolve this issue.
I am trying to run my first websocket app and refered this link to get some sample code . I simply created CustomEndPoint , WSClient class , html file and then ran it on netbeans IDE and it was working like a charm.
I tried to deploy it on tomcat server whose url is accessible using https by changing ws:// with wss:// and it worked on my dev environment but when I deployed the same code on Production env its throwing below error in console:
WebSocket connection to 'wss://xxxxxx-xxx.xxxx.com/websoc/ratesrv' failed: Error during WebSocket handshake: Unexpected response code: 404
For dev environment I below WS call is working :
wsocket = new WebSocket("wss://dev_ip:8443/websoc/ratesrv");
For Prod I am using(note the .com in url):
wss://xxxxx-xxxxx.xx.com/websoc/ratesrv
Do I need to explicitly provide the port number as well in PROD ?
Does your Tomcat version includes Websockets Runtime?
If it does you must delete all the Websockets dependencies from your WAR. Ensure that you call mvn clean after change scope to provided.
If not, you should include it. If you want to use Tyrus just put
<dependency>
<groupId>org.glassfish.tyrus</groupId>
<artifactId>tyrus-container-servlet</artifactId>
<version>1.12</version>
</dependency>
<dependency>
<groupId>org.glassfish.tyrus</groupId>
<artifactId>tyrus-client</artifactId>
<version>1.12</version>
</dependency>
And check that that there are no errors in the Tomcat console when deploy.
Try to use the latest version of tomcat.
tomcat8.5.20 worked for me.
Architecture:
Windows Client -> Wildfly JAX-RS Services -> JBoss 5.1.0.GA legacy system.
I am getting a java.lang.ClassCastException: javax.naming.Reference cannot be cast to com.interfaces.GroupBookingManagerRemote when communicating here between Wildfly JAX-RS Services and JBoss 5.1.0.GA legacy system.
As I am communicating from Wildfly to JBoss AS 5.1.0.GA I am attempting to connect using JNDI.
In my Wildfly Server Maven pom I include:
<dependency>
<groupId>jboss</groupId>
<artifactId>jnp-client</artifactId>
<version>4.2.2.GA</version>
</dependency>
This gives me access to the required org.jnp.* classes and interfaces.
I simply use the following code to connect to my remote machine and retrieve back a GroupBookingManager. However the issue appears when I attempt to cast the class to the interface GroupBookingManagerRemote.
Properties env = new Properties();
env.setProperty(Context.PROVIDER_URL, "jnp://myremoteserver:1099");
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
InitialContext initialContext = new InitialContext(env);
Object ref = initialContext.lookup("MyEARFile/GroupBookingManager/remote");
if (ref != null) {
bookingManager = (GroupBookingManagerRemote) ref; // java.lang.ClassCastException: javax.naming.Reference cannot be cast
}
I have a myclient.jar file which I have added to my Wildfly application that contains the remote interface GroupBookingManagerRemote.
Does anyone see any issue with what I have done?
Thanks,
Darren
Thanks for your help Gimby,
I found the answer myself after a bit more messing about.
From Wildfly 8.1.0 (client) -> JBoss AS 5
You do not require any JBoss 5 jars
Firstly you need a reference to the interface that you wish to use on the client side. This can be in a your-project-client.jar. If using Maven you can create a repository and build the Maven directory structure using mvn
mvn install:install-file -DlocalRepositoryPath=DirectoryName -DcreateChecksum=true -Dpackaging=jar -Dfile=Path-to-you-project-client.jar -DgroupId=YourGroupId -DartifactId=YourartifactId -Dversion=1.0
Then in order to connect to the remote machine and cast the interface back to your-interface, you use:
final Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, org.jboss.naming.remote.client.InitialContextFactory.class.getName());
env.put(Context.PROVIDER_URL, "remote://remoteserver:4447");
InitialContext initialContext = new InitialContext(env);
This uses Wildfly remote:// which is in remote naming and ejb in wildfly-ejb-client-bom
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<version>8.1.0.Final</version>
<scope>compile</scope>
<type>pom</type>
</dependency>
And I also required this dependency for communication
<dependency>
<groupId>org.jboss.xnio</groupId>
<artifactId>xnio-nio</artifactId>
<version>3.2.2.Final</version>
<scope>compile</scope>
</dependency>
and this one for the remote naming.
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-remote-naming</artifactId>
<version>2.0.1.Final</version>
</dependency>
Also note the port is not the ususal port for JBoss 5 JNDI:1099 this is the Default Remoting Port : 4447
Object ref = initialContext.lookup("ejb:Your-EAR/YourClass/remote!" + YouClass.class.getName());
You can then cast your reference to your interface and use it as normal.
Hope this makes sense.