I am using Jmeter to hit an https url which is behind firewall and i am using a proxy.
When I am using wget, I get thhis error:
--2014-12-12 16:14:49-- https://xxx.company.com/
Resolving proxy.net... xx.xx.xx.xx
Connecting to proxy.net|xx.xx.xx.xx|:80... connected.
ERROR: certificate common name "yyy.company.COM" doesn't match requested host name "xxx.company.com".
To connect to xxx.company.com insecurely, use '--no-check-certificate'.
After using the --no-check-certificate option wget is working fine.
But when I'm running wget through Jmeter,I am getting connection timed out error. Can anybody help me, how can i use --no-check-certificate option in Jmeter.
I am using Jmeter 2.9.
By default JMeter does not validate certificates so your issue is not what you think it is.
If wget works on the same machine where you get the timeout in JMeter, check that JMeter uses the same proxy configuration:
See this:
http://jmeter.apache.org/usermanual/get-started.html#proxy_server
echo "check_certificate = off" >> ~/.wgetrc
Related
I have tried to do distributed testing with two servers for a request which requires two way SSL handshaking. This is working fine when we are not using remote hosts for testing
sh jmeter.sh -n -t sample_Load_Test/sample_test.jmx -l sample_report/Log/results.jtl -e -o sample_report/Dashboard/
Jmeter Success:
But on trying to use the remote hosts for the same jmx file, the SSL handshake is failing. I have put the same same jmeter.p12 and truststore.jks in all the servers which are used for distribute testing.
Command used:
sh jmeter.sh -n -t sample_test/sample_load_test.jmx -l sample_report/Log/results.jtl -e -o sample_report/Dashboard/ -r -Jserver.rmi.ssl.disable=true
Please see the error that I am getting
Jmeter Failure:
<httpSample t="20" it="0" lt="0" ct="20" ts="1545068074631" s="false"
lb="HTTP Request" rc="Non HTTP response code:
javax.net.ssl.SSLHandshakeException" rm="Non HTTP response message:
Received fatal alert: handshake_failure"
Does anyone knows what I am doing wrong here
I can think of 2 possible causes:
You use different JRE versions on master and slaves and they have different SSL configuration in terms of storing certificates. Make sure you use exactly the same Java runtime everywhere and configuration is the same.
Your test relies on client certificates and on one of the slaves you don't have them defined in system.properties file or in SSL Manager make sure to use the same JMeter version and the same set of config files and external data files on each slave.
Get used to look into jmeter.log and/or jmeter-server.log files - in the majority of cases you should get the reason of the failure or unexpected behavior from the log.
I'm setting up a domain registry as described here:
https://docs.docker.com/registry/deploying/
I generated a certificate for docker.mydomain.com and started the docker using their command on my server:
docker run -d -p 5000:5000 --restart=always --name registry \
-v `pwd`/certs:/certs \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
registry:2
I've started the docker and pointed to certificates I obtained using letsencrypt (https://letsencrypt.org/).
Now, when I browse to https://docker.mydomain.com:5000/v2/ I will get a page with just '{}', with a green lock (succesful secure page request).
But when I try to do a docker login docker.mydomain.com:5000 from a different server I see a error in the registry docker:
TLS handshake error from xxx.xxx.xxx.xxx:51773: remote error: bad certificate
I've tried some different variations in setting up the certificates, and gotten errors like:
remote error: unknown certificate authority
and
tls: first record does not look like a TLS handshake
What am I missing?
Docker seams to not support SNI : https://github.com/docker/docker/issues/9969
Update : Docker now should support SNI.
It's mean, when connecting to your server during the tls transaction, the docker client do not specify the domain name, so your server show the default certificate.
The solution could be to change to default certificate of your server to be to one valid for the docker domain.
This site works only in browsers with SNI support.
To check if your (sub-)domain works with clients not SNI-aware, you can use ssllabs.com/ssltest : If you DONT see the message, "This site works only in browsers with SNI support. " then it will works.
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.
I am trying to configure loggly in apache in my ubuntu machine.
What I have done is
curl -O https://www.loggly.com/install/configure-apache.sh
sudo bash configure-apache.sh -a XXXXXX -u XXXXXX
After entering the last line it's saying
ERROR: Apache logs did not make to Loggly in time. Please check network and firewall settings and retry.
Manual instructions to configure Apache2 is available at https://www.loggly.com/docs/sending-apache-logs/. Rsyslog troubleshooting instructions are available at https://www.loggly.com/docs/troubleshooting-rsyslog/
Any idea why it's showing and how to solve it?
This is likely a network issue or a delay in sending the logs or even an issue with the script. Check out the following link that has the manual instructions. https://www.loggly.com/docs/sending-apache-logs/ that you can follow and use to verify the script created the configuration files correctly.
This might just be my rookie knowledge of Docker,
but I can't get the networking to work.
I'm trying to run a Mule-server via the pr3d4t0r/mule repository.
I can run it, hot-swap applications but I can reach it.
I can run a local server without Docker, and it works flawlessly.
But not when I try it with Docker.
When I try to do a simple curl command I get "curl: (56) Recv failure: Connection reset by peer"
curl http://localhost:8090/Sven
I have tried exposing the ports via -P and separately via -p 8090:8090 but no luck.
When the docker is running it blocks the ports (I tried running Docker and the normal server at the same time but the normal one said the ports where already in use).
When I try another Image like jboss/wildfly and I use -p 8080:8080 there's no problem, it works perfectly.
The application in the mule-server will log and respond a simple "hello World", the output says that the application is deployed, but no messages or logging while I try to reach it.
Any suggestions?
In my case it was actually the app that was configured incorrectly. It had localhost as host. It should have been 0.0.0.0 without this it was acting only on localhost aka the docker container but not from outside of it.
You should not need to use -net=host.
So check if there's a configuration
In application.properties need set 0.0.0.0 ip not 127.0.0.0.
error
"curl: (56) Recv failure: Connection reset by peer"
mean that no process in docker image listening to the port. Option -p is bind of port in host system and image.
-p <port in host os to be binded to>:<port in container>
So, check your image, maybe your app in container use different port and you need
-p 8080:8090
if you have this , comment or remove it, server.address=localhost in your application.properties