When trying out this tuturial => https://redis.io/topics/encryption
I keep getting this error on my local mac and remote linux:
Error accepting a client connection: error:1408F10B:SSL routines:ssl3_get_record:wrong version number (conn: fd=11)
The only difference is I run the command like this:
sudo ./src/redis-server /etc/redis/redis-6.2.6.conf
redis-6.2.6.conf
tls-cert-file /Users/dwesley/Documents/redis-6.2.6/tests/tls/redis.crt
tls-key-file /Users/dwesley/Documents/redis-6.2.6/tests/tls/redis.key
tls-ca-cert-file /Users/dwesley/Documents/redis-6.2.6/tests/tls/ca.crt
tls-dh-params-file /Users/dwesley/Documents/redis-6.2.6/tests/tls/redis.dh
tls-port 6379
tls-replication yes
tls-cluster yes
The certs got corrupted some how on generation, it works with properly generated certs.
Related
I am trying to use the wget binary for windows, in order to download an entire website onto a USB drive. I tried to run the following wget command, but it just failed. I don't know why. I don't know how to read the following error message.
with http:
E:\gardening> wget --mirror --convert-links --html-extension --no-timestamping --no-clobber -erobots=off --page-requisites --user-agent=Mozilla http://www.eattheweeds.com/
--2022-07-12 17:48:33-- http://www.eattheweeds.com/
Resolving www.eattheweeds.com... 45.60.22.231
Connecting to www.eattheweeds.com|45.60.22.231|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.eattheweeds.com/ [following]
--2022-07-12 17:48:33-- https://www.eattheweeds.com/
Connecting to www.eattheweeds.com|45.60.22.231|:443... connected.
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Unable to establish SSL connection.
with https:
E:\gardening> wget --mirror --convert-links --html-extension --no-timestamping --no-clobber -erobots=off --page-requisites --user-agent=Mozilla https://www.eattheweeds.com/
--2022-07-12 17:45:38-- https://www.eattheweeds.com/
Resolving www.eattheweeds.com... 45.60.22.231
Connecting to www.eattheweeds.com|45.60.22.231|:443... connected.
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Unable to establish SSL connection.
I got my wget from this website.
https://sourceforge.net/projects/gnuwin32/files/wget/1.11.4-1/wget-1.11.4-1-setup.exe/download?use_mirror=cfhcable
Could my version of wget have something to do with this?
GNU Wget 1.11.4
Copyright (C) 2008 Free Software Foundation, Inc
Edit:
I downloaded wget version GNU Wget 1.21.3 built on mingw32 and it worked!
https://eternallybored.org/misc/wget/
https://builtvisible.com/download-your-website-with-wget/
The problem is your version of wget do not support new versions of TLS. And the web site need TLS v1.1 or 1.2. As you found you need new version of wget
As you use Windows next time maybe will be wise to use Power Shell which have incorporated version of wget
I'm trying to setup a redis cluster using redis 6.0.10 compiled with TLS support. This is part of config related to TLS and cluster :
port 0
tls-port 6390
tls-cert-file /usr/local/redis6/tls/redisTLS.pem
tls-key-file /usr/local/redis6/tls/redis.key
tls-ca-cert-file /usr/local/redis6/tls/redistlschain.crt
tls-replication yes
tls-cluster yes
tls-auth-clients no
cluster-enabled yes
also i'm using requirepass option. I have 3 nodes each has 2 instances. Each has similar config with the same certs and key.
When i try to create a cluster with following command:
/usr/local/redis6/bin/redis-cli --tls --cert /usr/local/redis6/tls/redisTLS.pem --key /usr/local/redis6/tls/redis.key --cacert /usr/local/redis6/tls/redistlschain.crt -a somepass -p 6390 --cluster create 10.1.22.11:6390 10.1.22.11:6391 10.1.22.12:6390 10.1.22.12:6391 10.1.22.13:6390 10.1.22.13:6391 --cluster-replicas 1
it stuck on connecting nodes. In the log files i see following errors:
Accepting cluster node connection from 10.1.22.11:41398
Error accepting cluster node connection: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
It seems like an issue with certificate but when i use those certificates with redis-cli utility or other redis clients they work successfully. I can connect to redis instance and execute commands.
So it's not clear what should be fixed with certificates setup.
Is it something wrong with server certificate ? Or i need a client certificate in addition?
I have an option tls-auth-clients set to "no" so expected that client certificate is not needed ( also docs mention this).
Also do i need to have different server certificate for each node or it's ok to have the same on all nodes?
Any help would be appreciated.
Thanks
I am trying to get Redis 6 (with TLS enabled during compilation, tests after compilation were successful) to work. I am using Lets Encrypt certificate and following configuration:
tls-port 63790
tls-cert-file /etc/letsencrypt/live/myserver.net/cert.pem
tls-key-file /etc/letsencrypt/live/myserver.net/privkey.pem
tls-ca-cert-dir /etc/letsencrypt/live/myserver.net/
tls-auth-clients no
tls-protocols "TLSv1.2 TLSv1.3"
and this client command from localhost
redis-cli --tls --cert /etc/letsencrypt/live/myserver.net/cert.pem --key /etc/letsencrypt/live/myserver.net/privkey.pem --cacert /etc/letsencrypt/live/myserver.net/fullchain.pem -h myserver.net -p 63790 -a password
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
Could not connect to Redis at myserver.net:63790: SSL_connect failed: certificate verify failed
this is output from redis log:
Error accepting a client connection: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
While I am using openssl client with same certificates, i am able to connect and get ping reply from Redis server
No matter if I change
tls-ca-cert-dir /etc/letsencrypt/live/myserver.net/
to
tls-ca-cert
on server side
or
--cacert /etc/letsencrypt/live/myserver.net/fullchain.pem to chain.pem on client side
I tried to all versions of
tls-protocols ""
and change
tls-auth-clients no
to
tls-auth-clients optional
but I am still stuck with same error
OpenSSL version is 1.1.1
Redis version is 6.0.8
OS: Ubuntu 20.04
Can you help me to find out reason why is TLS not working, please?
Thank you
Wil
Ahh, SOLVED!
I was putting wrong CA chain. I had to chain root and intermediate certs downloaded from LE website into new file. It may come handy for someone with same problem.
I am trying to download files from an https site and keep getting the following error:
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Unable to establish SSL connection.
From reading blogs online I gather I have to provide the server cert and the client cert. I have found steps on how to download the server cert but not the client cert. Does anyone have a complete set of steps to use wget with SSL? I also tried the --no-check-certificate option but that did not work.
wget version: wget-1.13.4
openssl version: OpenSSL 1.0.1f 6 Jan 2014
trying to download all lecture resources from a course's webpage on coursera.org. So, the URL would look something like this: https://class.coursera.org/matrix-002/lecture
Accessing this webpage online requires form authentication, not sure if that is causing the failure.
It works from here with same OpenSSL version, but a newer version of wget (1.15). Looking at the Changelog there is the following significant change regarding your problem:
1.14: Add support for TLS Server Name Indication.
Note that this site does not require SNI. But www.coursera.org requires it.
And if you would call wget with -v --debug (as I've explicitly recommended in my comment!) you will see:
$ wget https://class.coursera.org
...
HTTP request sent, awaiting response...
HTTP/1.1 302 Found
...
Location: https://www.coursera.org/ [following]
...
Connecting to www.coursera.org (www.coursera.org)|54.230.46.78|:443... connected.
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Unable to establish SSL connection.
So the error actually happens with www.coursera.org and the reason is missing support for SNI. You need to upgrade your version of wget.
You probably have an old version of wget. I suggest installing wget using Chocolatey, the package manager for Windows. This should give you a more recent version (if not the latest).
Run this command after having installed Chocolatey (as Administrator):
choco install wget
I was in SLES12 and for me it worked after upgrading to wget 1.14, using --secure-protocol=TLSv1.2 and using --auth-no-challenge.
wget --no-check-certificate --secure-protocol=TLSv1.2 --user=satul --password=xxx --auth-no-challenge -v --debug https://jenkins-server/artifact/build.x86_64.tgz
One alternative is to replace the "https" with "http" in the url that you're trying to download from to just circumvent the SSL connection. Not the most secure solution, but this worked in my case.
I was having this problem on Ubuntu 12.04.3 LTS (well beyond EOL, I know...) and got around it with:
sudo apt-get update && sudo apt-get install ca-certificates
Basically your OpenSSL uses SSLv3 and the site you are accessing does not support that protocol.
Just update your wget:
sudo apt-get install wget
Or if it is already supporting another secure protocol, just add it as argument:
wget https://example.com --secure-protocol=PROTOCOL_v1
Below command for download files from TLSv1.2 website.
curl -v --tlsv1.2 https://example.com/filename.zip
It`s worked!
Otherwise might be just simpler to use curl instead.
There is no peculiar need to specify any option and can be simply:
curl https://example.com/filename.zip
with curl there is no need to add the -v option when facing the wget SSL error.
Hey I'm having an issue getting ssh X forwarding to work. The setup is I'm sshing into my ubuntu VM off OSX Yosemite host machine.
I already installed xQuartz on OSX, xauth on ubuntu, and I believe I've have all the correct options set in ssh_config files.
I get the
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
X11 forwarding request failed on channel 0
message when opening a connection with ssh -X, and when I tried to run an X application:
xterm: Xt error: Can't open display:
xterm: DISPLAY is not set
I have the identical setup on my other machine except running Mavericks and it works fine, is there something specific to Yosemite specific I have to worry about?
Note that some incomplete answers might lead to security flaws.
Using ssh -Y means here having fake xauth information which is bad!
ssh -X should work since XQuartz, once enabled, uses xauth. The only problem is that ssh is looking for xauth in /usr/X11R6/bin and on macOS with XQuartz it is in /opt/X11/bin
Secure solution:
Enable the first option in the Security tab of preferences (Cmd-,) which enables authenticated connections.
Edit ~/.ssh/config, add XAuthLocation /opt/X11/bin/xauth to the host config.
ssh -X your_server works in a secure manner.
Ensure xauth is installed on the destination host.
On macOS Sierra, I now have to do ssh -Y instead of ssh -X to get a display from a linux machine to work on my Mac.
I received the same warning as you after upgrading to Yosemite.
After I added ForwardX11Trusted yes in my ~/.ssh/config file, the warning disappeared.
Do you have the following lines in your ~/.ssh/config file for enabling Trusted X11 forwarding?
Host APPROPRIATE_HOSTNAME
ForwardX11Trusted yes
ForwardX11 yes
OTHER_OPTIONS
Gilles Gouaillardet has the answer that solved this for me. Edit ~/.ssh/config to contain
Host *
XAuthLocation /opt/X11/bin/xauth
and ssh -X hostname now works (XQuartz 2.7.11, macOS 10.4 Mojave)
I already had the latest XQuartz 2.7.11 installed, but I think I've also updated the OS a few times since then. I reinstalled XQuartz 2.7.11, and now it is working fine.
ForwardX11Trusted is required even for connections you think are untrusted when your X server doesn't have the SECURITY extension (Apple servers have a ton of visuals that take up over 100 lines, so I suggest "xdpyinfo | grep SECURITY" to check; if that returns no output, you don't have it). There may be other reasons and exceptions, but this worked for me.
I've just downloaded the latest X11 version and it worked again
I just hit this issue using Mac OS X 10.6.8 to Linux Debian 9.
None of the solutions provided worked.
Root cause was: loopback interface was "DOWN" on the target Linux host.
I had to type the following on the target host to fix the issue
ip link set lo up
Same as answered by user Xvalidated above. but there was no ssh_config file in my .ssh directory.
1. copy ./etc/ssh_config to ~/.ssh/ #file if not there
2. edit
Host hostname
ForwardX11Trusted yes
ForwardX11 yes
As answered before, I would like to add one more thing which will work to reinstall X-supporting software.
When you login the cluster, do not use -X or -Y options.
Example:
ssh -Y remotelogin: gives me X11 related warning.
ssh remotelogin: No warning, works fine.