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
Related
I'm trying to enable SSL on a Artemis broker and always get this exception when trying to connect:
Exception in thread "main" ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ219013: Timed out waiting to receive cluster topology. Group:null]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:743)
The code I use to connect is just this:
ActiveMQClient.createServerLocator("tcp://localhost:5500").createSessionFactory();
This is from a fresh install of Artemis 2.23.1 and the only thing I changed from the default broker configuration was to add this acceptor in broker.xml:
<acceptor name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.jks;keyStorePassword=securepass</acceptor>
I generated the keystore and truststore using the script provided in this example.
I had first tried a keystore with a cert that is valid for my domain (using a domain-qualified host name in createServerLocator()) but that also gave me the timeout. That is when I went back to fresh installs and tried going through the SSL example.
Various attempts with invalid paths/passwords/certs threw exceptions that led me to what to fix, but so far haven't been able to see what I did wrong with a generic timeout discovering cluster topology.
Anybody have ideas?
You need to specify sslEnabled=true on the client's URL as well so it knows to use SSL, e.g.:
ActiveMQClient.createServerLocator("tcp://localhost:5500?sslEnabled=true").createSessionFactory();
This is done for the JMS connection in the ssl-enabled example which you cited here.
Also, if you're using self-signed certificates then you'll need a truststore for your client as well and you'll need to configure those settings on the client's URL (just like in the example).
I am new to HTTPs. In our application to integrate with another system we were given HTTPs URLs along with their certificates. Our team added those certificates in the test store. Now when we are sending request on those URLs, we are getting “Unsupported or unrecognized SSL message”.
And if I do curl -v on that URL, I get error:1408F10B:SSL routines:ssl3_get_record:wrong version number.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
Both of these errors are due to the same reason?
It is very likely that the server does not speak TLS at all.
The client will start with the TLS handshake and the server will reply to this with some non-TLS response. The client expect the server to do its part of the TLS handshake though. Thus it will try to interpret the servers as response as TLS. This will lead to strange error messages depending on the TLS stack used by the client.
With OpenSSL based stacks it will often result in wrong version number, since the trying to extract the TLS version number for the expected TLS record and get some unexpected results since the server did not actually send a TLS record.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
If this is exact the URL you are supposed to use (i.e. no simply changing of http:// to https:// on your site) then it is likely a server side problem. But it might also be a problem of some middlebox or software in the network path to the server, like some antivirus, firewall or captive portal hijacking your data and denying access to the remote system with an error message.
In my case, I had on apache2 another badly configured virtual host. On the other wrong virtual host there was a http virtual server on port 443!!!
The second virtual host was correct but apache cannot use different protocols on the same port for different virtual hosts.
After removing the http on port 443 configuration all other https hosts worked and error
error:1408F10B:SSL routines:ssl3_get_record:wrong version number"
disapeared
We have recently upgraded our Tomcat version to 9.0.20 from Tomcat 7 and our users report that they are not able to connect to our system any longer due to the below error.
Error while sending message: Could not send Message. Peer sent alert: Alert Fatal: handshake failure
We have checked the SSL certificates and everything is in place and even we have verified the TLS version in the source SAP system. However this issue is noticed only in SAP systems who are using our webservices. So I would like to know what details I need to check at SAP side to fix this issue.
Please note that when I switch back to Tomcat7, the connection works perfectly fine. I have compared the server.xml of both the versions and don't see any difference apart from the below line.
Tomcat 7: protocol="HTTP/1.1"
Tomcat 9: protocol="org.apache.coyote.http11.Http11NioProtocol"
Appreciate response.
Thanks!
The issue was apparently with the cipher suites being used in SAP system. Adding new cipher suites which supports TLS 1.1 and TLS 1.2 worked and the issue was resolved.
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.
When I used set doc=db.GetDocumentByURL(url,1,1,,,,,False) to get a page/file under http, it returned the web page/file successfully as a Notes document.
But when I used set doc=db.GetDocumentByURL(url,1,1,username,password,,,False) to get an ssl page/file under https, where url is like "https://docs.google.com/document/d/xxxxoooo/edit", it failed and the remote console showed the error messages:
SSL Error: Keyring File access error
Connection interrupted: SSL Error: Bad or missing remote certificate
Can't db.GetDocumentByURL() access an ssl page/file? What should I do?
Assuming you are using Windows - make sure that IE can open the page. I've seen this problem in case the server's SSL certificate was self-signed and installing it in IE solved the problem.