how can I disable hostname verification on WSO2 Api Manager 2.5?
I'm getting the following error, having WSO2-AM and WSO2-EI 6.3 deployed on two different docker containers:
[2018-11-15 11:31:06,194] WARN - login:jag Not Retrieving Pending Tasks. Check BPS Connectivity. javax.net.ssl.SSLException: hostname in certificate didn't match: <100.64.45.16> != <localhost>
I tried all the possible configurations described here, but they don't disable it:
https://docs.wso2.com/display/ADMIN44x/Enabling+HostName+Verification#EnablingHostNameVerification-hostname_verification_newConfiguringhostnameverification(Carbon4.4.17onwards)
Any suggestion?
Related
I'm testing kafka cluster creation using let's encrypt staging certs. After creating, on my machine, I run the kafka-provided kafka-console-consumer.sh and kafka-console-producer.sh scripts. When I ran with let's encrypt production, it worked fine. But now that I'm using staging certs, I get this when I run the producer:
ERROR [Producer clientId=console-producer] Connection to node -1 (2.kafka.mysite.com/10.1.17.191:9092) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
I use these properties for producer script:
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="kafka" password="secret";
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
I'd like to give the option to ignore TLS, and I'd like it to be some parameter I can toggle (on the cluster or on the client) to allow it. How can I achieve this? For anyone familiar with Rabbitmq, I think it's similar to VERIFY_PEER=false, aka VERIFY_NONE.
The kafka configuration has setting
ssl.client.auth
Its value could be set as required,requested or none. You could set it to requested.his means client authentication is optional. unlike requested , if this option is set client can choose not to provide authentication information about itself
https://docs.confluent.io/current/installation/configuration/broker-configs.html
I'm using kafka version kafka_2.12-2.0.0 and received the below error after enabling SSL authentication. It seems to be working fine with previous versions: kafka_2.12-1.1.0, 2.11-0.10.2.2 etc.
I don't understand why it is not working with latest version 2.11-0.2.0.0? Has anyone observed the same issue that I'm facing right now with 2.0.0 version.
Below is my test environment docker config file.
listeners=PLAINTEXT://:9092,SSl://:9093
ssl.client.auth=required
ssl.keystore.location=/path/to/server.keystore
ssl.keystore.password=<Key store password>
ssl.key.password = <private key password>
ssl.truststore.location=/path/to/truststore.keystore
ssl.truststore.password=<trust store password>
security.inter.broker.protocol=SSL
And here's the error:
[2018-10-01 09:33:38,984] ERROR [Controller id=1, targetBrokerId=1] Connection to node 1 failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
Can someone help me ?
Without more details it's hard to tell for sure, but 2.0.0 introduced a change of behaviour related to the handling of SSL connections.
As mentioned in the 2.0.0 upgrade notes, the broker setting ssl.endpoint.identification.algorithm is now set to https. This enforces hostname verification to prevent "man-in-the-middle" attacks.
To restore previous behaviour, you need to explicitely set this to an empty string.
ssl.endpoint.identification.algorithm=
Was also facing a similar issue. My issue, I was having Kafka server 1.1.1 running and was using Kafka client 2.1.0 to push records. Changing Kafka client to 1.1.1 solved my issue.
Hope this helps.
Coverity instance details:
SA Version: 8.6
Connect: 8.7
While trying to upload defects to coverity instance, the following error is seen
Connecting to server xxx.xxx.com:9090
[ERROR] SSL solicitation failed: Server's SSL preference is "preferred" but SSL is not configured on the server.
Though we haven't configured https (ldap ssl) in our instance, cov commit defects fails with SSL error.
Is this something introduced newly in coverity connect 8.7? Or an environment settings issue?
You may have configured Coverity Connect to use SSL.
Please check SSL settings in cim.properties
grep commit.encryption <coverity-connect-install-path>/config/cim.properties
commit.encryption should not be present or set to none if you do not intend to use SSL. Alternatively open server.xml to check if SSL is enabled. Connector section is commented when SSL is disabled
$ grep -A2 'Enable this connector to add SSL' <coverity-connect-install-path>/server/base/conf/server.xml
<!-- Enable this connector to add SSL support. -->
<!--
<Connector port="****"
I am trying to connect from a windows computer to a ubuntu linux server, It is about cvs, I want to do a checkout. I use smartcvs 7.1.9.
I get this error when I try to connect to the server: (Project > Checkout > Next)
Authentication Failed: You could not get authenticated by the
CVS-server. Details: I/O-Exception: Failed to negotiate a transport
component [diffie-hellman-group-exchange-sha1]
[diffie-hellman-group14-sha1]
Anybody ideas what I can do?
This is a cvs server issue.
SmartCVS uses the diffie-hellman key exchange method for authentication which is known to have security issues. Therefore it has been disabled by default in current standard openssh(d) server configurations.
If you know what you are doing and don't care about the security implications, just add the following lines to sshd_config:
starts here
KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com,chacha20-poly1305#openssh.com,blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
ends here
If you're on linux.. recreate the keys and restart the opensshd service:
dpkg-reconfigure openssh-server
/etc/init.d/ssh restart
Regards
Erwin
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