is there a way to determine the TLS Version in the traefik access.log.
We want to know how many requests are made with older TLS Versions.
I don't find any option to enable such a feature.
Is there a way to do that ?
traefik 1.7 is not able to log TLS verisons:
https://docs.traefik.io/v1.7/configuration/logs/#list-of-all-available-fields .
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.
Context :
ElastAlert v0.1.29 included in Container Docker on OpenShift Orchestrator
Elasticsearch 2.4.4 exposed by Openshift agregate_logging (with Oauth2)
Hello,
From Elastalert, i want to connect to Elasticsearch.
The authenticate of Elastic use oauth2.
The oauth2 requires the X-Proxy-Remote-User and the token in the header of the requests :
Ex:
curl -k -H "Authorization: Bearer $token" -H "X-Proxy-Remote-User: $(oc whoami)" -H "X-Forwarded-For: 127.0.0.1" https://es.example.test/_cat/indices
I believe that ElastAlert doesn't support the authenticate Oauth2 by token. Can you confirm?
Effectively, i don't think that client_key and client_cert tls options they are compatible ?
Thanks for your help
Regards
Loïc
From what I've read of the code, no, it only supports basic auth. This would be a nice feature if someone had the time to contribute.
wget fails to download through a proxy server with the following message: Invalid request -- HOST header was not sentUnable to establish SSL connection.
Example:
[root#foosrv0234ccpra ~]# wget https://packages.chef.io/stable/el/6/chefdk-0.18.26-1.el6.x86_64.rpm
--2016-09-27 16:57:44-- https://packages.chef.io/stable/el/6/chefdk-0.18.26-1.el6.x86_64.rpm
Resolving deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com (deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com)... 129.35.62.40
Connecting to deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com (deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com)|129.35.62.40|:8080... connected.
Proxy tunneling failed: Invalid request -- HOST header was not sentUnable to establish SSL connection.
[root#foosrv0234ccpra ~]# env|grep proxy
http_proxy=http://barsrvprx024ccpxa.ehn.sr.dev.sdc.mycomp.com:8080
https_proxy=http://barsrvprx024ccpxa.ehn.sr.dev.sdc.mycomp.com:8080
no_proxy=barsrvacp014ccpra,barsrvchf014ccpra.ssm.sdc.gts.mycomp.com,localhost,127.0.0.1,barsrvacp014ccpra.ssm.sdc.gts.mycomp.com
It took me a while to get through this, so I'm sharing the issue on StackOverflow. Please have a look at the answer below.
The problem above happens because HTTP 1.1 requires the client to provide a HOST header and the proxy server does not support HTTP 1.1 (refer to RFC 2616 for more details on this requirement).
Some alternatives:
Upgrade your proxy to support HTTP 1.1
Downgrade wget to a version that only supports HTTP 1.0 (wget v1.12 or below)
Find another way to force all HTTP calls to be made using 1.0 and not 1.1 (I haven't explore this possibility and I'm not sure how to do it... downgrading wget solved my issue)
I am getting the below error while making ssl connection with self signed certificate.
"Peer certificate cannot be authenticated with known CA certificates"
It is working fine with CA signed certificate.
I am setting the below using curl_easy_setopt().
curl_easy_setopt(MyContext, CURLOPT_CAPATH, CA_CERTIFICATE_PATH)
curl_easy_setopt(MyContext, CURLOPT_SSL_VERIFYPEER,TRUE);
The curl version:
libcurl-7.19.7-26
Openssl version is:
0_9_8u
Please let me know how to solve this issue.
By default CURL will generally verify the SSL certificate to see if its valid and issued by an accepted CA. To do this, curl uses a bundled set of CA certificates.
If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. Here's an example:
curl --noproxy -k \* -D - https://127.0.0.1:443/some-secure-endpoint
Security issue: This answer disables a security feature. Do not use this in production!
For php it is possible to switch off curl's verification of the certificate (see warning below) e.g. for curl_exec
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
http://php.net/manual/en/function.curl-setopt.php
(evaluate the security risk yourself, in my case it was on a partner company's server and the file required contained no secure information - just happened to be on a secure server)
We fixed a similar issue on CentOS 6 by updating curl to the latest version available in the standard repositories and installing the newest ca-certificates bundle:
yum update curl
yum install ca-certificates
libcurl performs peer SSL certificate verification by default. This is done
by using CA cert bundle that the SSL library can use to make sure the peer's
server certificate is valid.
If you communicate with HTTPS or FTPS servers using certificates that are
signed by CAs present in the bundle, you can be sure that the remote server
really is the one it claims to be.
Until 7.18.0, curl bundled a severely outdated ca bundle file that was
installed by default. These days, the curl archives include no ca certs at
all. You need to get them elsewhere. See below for example.
For more to know about Peer SSL Certificate Verification visit http://curl.haxx.se/docs/sslcerts.html
Though this error happened in the case of using git clone rather than with using curl, I've recently stumbled across an identical error message:
Peer certificate cannot be authenticated with known CA certificates
Similar to Arth's findings, something that worked for CentOS 6 (in order to successfully use HTTPS URLs with git clone for related GitLab repositories) involved updating the trusted certificates on the server (i.e., the server that is using HTTPS), using the following steps:
sudo yum install ca-certificates
sudo update-ca-trust enable
sudo cp /path/to/your_new_cert.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
Perhaps the same certificate steps can be applied for the case of curl (or other similar scenarios) for users on CentOS in the future.
Security issue: This answer disables a security feature. Do not use this in production!
In 'C'
curl_easy_setopt(curl_handle, CURLOPT_SSL_VERIFYPEER, 0);
worked for me
As we checked and observed/ Found in Centos 8 .
Due to Proxy issue your packages not allowing you to get accessible to update or download any packages.
try to add sslverify=0 in file /etc/dnf/dnf.conf
Its worked for me.
Also make sure you must have proper internet acess on your server.