I'm setting up a server with a couple of web services in Jboss 4.2.2. When I disable the SSL verification on the connector, all calls go through in SoapUI as well from a python script containing the same payload as the SoapUI script.
But when I enable the SSL verification with a connected keystore on the connector, all requests from SoapUI gets refused, with the following error:
Error getting response; org.apache.http.conn.HttpHostConnectException: Connection to https://1...8:2443 refused
My python-script still runs and successfully recieves the response as expected.
I have also linked the same keystore to the SSL settings in SoapUI, but without luck. I'm not familiar enough with SoapUI to know what I'm missing.
Anyone got an idea?
2443 isn't the default https connector port. Check it out on your server configuation. You can check the ports on which jboss is listening too using netstat, or directly use telnet to probe the connection.
Related
I'm trying to run this webrtc client/signaling server code, but after running the server with a new self-signed certificate I created by following the instructions of this tutorial, my chatclient.js couldn't connect to socket server:
connection = new WebSocket('wss://localhost:6503/', 'json');
this is the error displayed by chrome's console:
(chatclient.js:106) WebSocket connection to 'wss://localhost:6503/' failed:
Error in connection establishment: net::ERR_CERT_COMMON_NAME_INVALID
I then go to https://0.0.0.0:6503/ from chrome (the server is listening on port 6503), and this is the security tab from chrome inspector:
I'm guessing I need to set the correct common name during the generation of ssl certificate, to which I current set as 0.0.0.0:6503.
What should I set? Since this is a websocket's address and I have no idea which part to write?
Set it to localhost which is the same host you're trying to connect to. You do not need to include the port. Note that you will need a certificate in production.
You might also want to check the highly useful Chrome flag which ignores certificate errors on localhost: chrome://flags/#allow-insecure-localhost
I am able to reach my weblogic console over https connection but when I try to launch developer console that is setup as a managed server in the weblogic domain, it fails. However, I can reach the dev console over http port without any issues.
I checked the validity of certs installed my keystore and configured to enable ssl port in managed servers. I am not sure what I am missing here. Please advice if I am missing any additional checks/setups.
For eg,
http://<XXX.cname.com>:9005/console - works on http
https://<XXX.cname.com>:9009/edq - does not work on https
I verified from console that ports are right and ssl ports are enabled.
I've enabled SSL Listen Port from the Admin Console of Weblogic 11g Version: 10.3.6.0
I've created a self-signed cert following: https://oracle-base.com/articles/11g/weblogic-configure-ssl-for-a-managed-server
But when try https on the browser of a remote machine I get a timeout.
If I try from the local machine using: curl -Ik I get the proper response, it seems that only remote access is disabled.
Accessing via http works fine from my remote machine browser. I did also try telnet but it only works with 7001 but not with 7002 (my secure port). I've already tried changing the secure port number but the result is the same.
My Weblogic server is on a Centos running on VMware ESXi.
What could be blocking the remote SSL connection?
A timeout indicates a firewalling of some sort. As you say yourself if you try locally with curl it works. There is nothing else to check if locally you can but remotely you get a timeout.
I am forcing a dummy SSL for my localhost running through xampp. Now I am using web sockets which asks for 'wss:' instead of 'ws:'. But when using 'wss', I am getting the following Error:
WebSocket connection to 'wss://192.168.1.5/?aswin' failed: WebSocket opening handshake was canceled
I am new to this, I don't know what's causing this issue.
Remember to change the port number to a one different to the one you used for not secure connections. Some browsers get confused if suddenly a port becomes secure or viceversa.
Remember to use the hostname indicated in the certificate to connect and not the IP.
If you are using a self-signed certificate, use it for HTTPS so you can see the dialog for accepting that certificate. When accessing via WSS:// there is not certificate acceptance dialog, it will just fail to connect.
I have been trying to configure a simple pass through proxy using wso2 esb, which points to a REST service in https port.
I had tried doing the same using my development machine (Windows 7) and it is successful.
But when I try repeating the same in production server, in RHEL, I get The system cannot infer the transport information error in system log.
Things Tried
Created passthrough proxy service pointing to https://some.domain.in/something/something.
Tried CURL to https://some.domain.in/something/something and its shows the response properly
Imported certificate from the site to client-truststore.jks. Same was done locally and it worked.
in axis2.xml, edited <parameter name="HostnameVerifier">AllowAll</parameter>under https transporter
Error Message
When clicked in test in configuration console, I got the following message, Invalid address
CURL the proxy service URL, and got Empty response
Checked system logs and saw below logs
Am I missing out something?
I could see in the wso2-error-logs following messages
ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O
error: handshake alert: unrecognized_name
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
Then I realised that I was using java 1.6 locally but 1.7 in production.
And in Java 1.7 there are some changes in SSL handling
The JDK 7 release supports
the Server Name Indication (SNI) extension in the JSSE client. SNI,
described in RFC 4366 enables TLS clients to connect to virtual
servers.
In order to bypass this, I added JAVA_OPTS="-Djsse.enableSNIExtension=false" in wso2server.sh and restarted.
This solved my problem.
Not sure if this is the correct way though
This url helped me finally