I have a spring boot based microservice in which I am using Microsoft Azure Computer Vision API to read data from a PDF file. After containerizing the microservice, the container works fine and I am able to send/receive data to/from Computer Vision API on my machine. But, when I run this container on an Azure based Linux Virtual Machine, the container cannot communicate with the Computer Vision API and throws exception java.lang.RuntimeException: javax.net.ssl.SSLKeyException: RSA premaster secret error. Also, the spring-boot jar is able to communicate with Azure on VM and throws no such exception.
Do you think I need to pass any self-signed certificate to the container for it to be able to communicate smoothly?
I think the biggest advantage of using these containers is that it makes the code platform independent. So, why is this error thrown only on Azure VM and runs completely fine on my machine? Please advise.
java.lang.RuntimeException: javax.net.ssl.SSLKeyException: RSA premaster secret error
On local computer was working fine but when run the container on Azure Linux VM it is not working so there might be compatibility issue between Linux VM and Java JRE’s.
Based on above error the solution is Just remove the updated java version from your server Classpath and try to install the old java version
Please refer this link had the same discussion over here related to above error : https://community.oracle.com/tech/developers/discussion/1533888/another-rsa-premaster-secret-error
Second, try to set the SSL/TLS parameters in the java panel because An SSL certificate is a bit of code on your web server that provides security for online communications. When a web browser contacts your secured website, the SSL certificate enables an encrypted connection. It's kind of like sealing a letter in an envelope before sending it through the mail.
Supported SSL/TLS versions by JDK version
I was able to find out what the error was. There was nothing wrong with the JDK/JRE setup. The issue arose due to the version of docker engine installed on the Azure VM.
Azure based computer vision APIs required server to be TLS1.2 compliant, whereas the version of the docker engine installed on my machine was older and did not support TLS1.2. I was able to fix it after upgrading the docker engine to the latest version.
Related
I've got a windows forms app which is deployed through click once. The app was build with .net 4.7.2 and it uses the HttpClient API to access a couple of rest web services, which are hosted on an internal server. As you might expect, the services can only be accessed through HTTPS and the server is configured to suppport all TLS versions (btw, this is a 2016 windows server).
The intranet client app (ie, the windows forms app) is deployed across several internal sub-networks and everything is working well with the exception of a single PC (which belongs to a specific subnetwork - it's the only PC that is using this particular app). This PC will only be able to consume the services when the HttpClient is configured to use TLS 1.1.
Since we're using internal certificates (we have an internal certificate authority for our AD), I've already checked and the certificate with the public key of the entity is already present on the trusted certificate authorities container of the computer where the secure session can't be established through TLS 1.2.
The PC is running Windows 10 Pro (latest version), so it should support TLS 1.2. I've tried emulating the requests from Fiddler and the truth is that I'll only get the results when I configure it to use TLS 1.1.
Without setting the protocol to TLS 1.1, I can see that Fiddler says that the handshake hasn't been established and the service is never "executed".
Now, according to what I've read, I shouldn't have been getting any problems with the code. In fact, I shouldn't have to specify the TLS version (it looks like Windows 10 Pro has out of the box support for TLS 1.2 and that should be the default for WIndows 10. Since I'm using .NET 4.7.2, it should automatically use the system's default protocol), but the truth is that only using tls 1.1 (not tls 1.2!) allows for the secure channel to be established.
I've tried running the code in other machines and everything works out as expected (I can establish the secure channel with tls 1.1 or tls 1.2 or even let it use the system's default protocol).
Since I'm not really a network guy, can anyone point me in the right direction? Do you guys think this can be caused by a firewall? Any ideas?
I mean, it looks like the PC recognizes the certificate used in HTTPS session (if that wasn't the case, then I wouldn't be able to use TLS 1.1, right?), but it seems like there's something in the way that won't let me use TLS 1.2...
Thanks.
Luis
Check our official guidance for TLS: https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls
If it is one machine problem, I would recommend to create a simple HelloWorld app doing simple request, targeting the same .NET Framework (4.7.2) and then test that on the specific machine vs. other machines. That will tell you for sure if the problem is in your app or in machine/network settings.
I am trying to connect to a remote sonarqube 6.2 server from Sonarlint 3.2 plugin in eclipse neon. I am able to connect to my local server http://localhost:9000.
But When I am trying to hit the remote sonar server I am getting below error:
Fail to request https://xxxxxxxxxxxxxx:xxxx/xxx/api/system/status
Please advise.
I ran into this problem myself using SonarLint 3.1 and SonarQube 6.7.
In IntelliJ I kept running into this error message
Failed to connect to the server. Please check the configuration.
Error: Fail to request https://<SONARQUBE>/api/system/status
However I could access that URL through my browser without any issues.
When you WireShark the requests coming from the browser and the IDE you can see that the cypher suite is quite different and that the IDE plugin gets a TLS handshake failure.
That lead me to discover that Java still ships with limited strength cryptographic functions. That’s either because of US export policy or because nobody has gotten around to fixing it. The internet isn’t quite sure.
Either way, you can download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
Once I installed those onto the IntelliJ JVM, I no longer got the underlying TLS handshake failure when trying to connect to SonarQube and the connection works.
My set up is the following SonarQube 6.0 + Nginx (two docker containers) hosted on a machine on azure.
I've configured the sonar-auth-aad and it's working like a charm in the browser.
I've added the self signed certificate to the store of the local machine so I don't get an error anymore.
My machine has Vs2015 update 3 and the latest version as of today for sonarlint.
When I try to connect to the server using my AAD logins, doesn't work, although it works with plain sonarqube credentials.
Is it something not supported yet or can I configure something in order to make it work?
Thanks!
We're providing the ability from SonarLint to connect to a SonarQube server with a standard login/password just for backward compatibility reasons with SonarQube 4.5. But the official way to establish this connection is by :
Generating a user authentication token in SonarQube (See http://docs.sonarqube.org/display/SONAR/User+Token)
Configure SonarLint to use this token (and not a login/password)
From there you'll manage to have SonarLint for Visual Studio establishing a connection with your SonarQube server.
We install liferay6.2 in windows dedicated server 2008 r2. Liferay sever is working smoothly in the server but when we are trying to access it from browser then we are unable to access it. Error: server not found. In Liferay we have one portlet for video conference and it is also working fine. We can access the server through RDP(Remote Desktop) but whenever trying to access through browser fail to find the server in web.
May be this issue can be easily handle by the network admin or may be by any Liferay developer.
Does your dedicated server have a public (routed) IP address? Also, check firewalls that might block port 8080 if you have not changed the default port. As you say Liferay is running smoothly - you just can't access it - your problem is most likely rather related to the network configuration, not to Liferay itself
we are doing worklight app on a android and a desktopenvironment(for facebook) that works fine on the liberty profile server (developer worklight environment).
Know we need to post this app on Facebook but to do this we need to use the https protocol on our WAS server, to do this we set the ip, port, protocol: to our external server, and deploy our app with build for remote server, but when the app tried to call an adapter on the server, the Firefox console returns us this:
[09:58:50.675] "response [https://[publicIP]:[port]/WorklightPocProj/apps/services/../../invoke] success: /*-secure-
{"challenges":{"wl_antiXSRFRealm":{"WL-Instance-Id":"ih80d8pjg6la8ubccb7503b936"}}}*/"
and
[09:58:50.675] "defaultOptions:onFailure Procedure invocation error."
The application security on our WAS server is disabled and the ip/port are reachable too.
if i add to the XML adapter on the procedures securityTest="wl_unprotected" the app runs correctly, but i don't to do this workaround
Is there any configuration that we are missing on the app or in our WAS server?
A lot of time since this question but just for trying to help people that hit this question because of the search "defaultOptions:onFailure Procedure invocation error".
Also facing this issue in Worklight 6.1
In my case I faced this issue because I had the following configuration in the adapter .xml:
<procedure name="anyMethod"></procedure>
This works in the development server, but in a stand alone server (at least in WAS) you have to change it for:
<procedure name="submitAuthentication" securityTest="wl_unprotected"></procedure>
In both cases it is unprotected.