I have setup docker in non-ssl mode by editing /etc/default/docker and setting DOCKER_OPTS="-H=0.0.0.0:2375".
Now when I start docker and connect to it using curl curl -sv http://10.24.16.17:2375/v1.22/containers/json, I get some response.
When I secure the docker using certificates (ca.pem, server-key.pem, server-cert.pem) and editing /etc/default/docker
DOCKER_OPTS="--tlsverify --tlscacert=/home/ubuntu/certs/ca.pem --tlscert=/home/ubuntu/certs/server-cert.pem --tlskey=/home/ubuntu/certs/server-key.pem -H=0.0.0.0:2376"
I am not able to connect service using curl:
curl -sv https://10.24.16.17:2376/v1.22/containers/json
I get the following output:
* Hostname was NOT found in DNS cache
* Trying 10.24.16.17...
* Connected to 10.24.16.17 (10.24.16.17) port 2376 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
I am able to run docker ps -a command using CLI though, only cURL to hit the API endpoint does not work.
When I try curl -sv --cacert /home/ubuntu/certs/ca.pem https://10.24.16.17:2376/v1.22/containers/json, I get:
* Hostname was NOT found in DNS cache
* Trying 10.24.16.17...
* Connected to 10.24.16.17 (10.24.16.17) port 2376 (#0)
* successfully set certificate verify locations:
* CAfile: /home/ubuntu/certs/ca.pem
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
* Closing connection 0
I read somewhere that the above error may be due to corrupt ca.pem file, but that may not be the case as the command docker ps -a was able to connect to docker host using the same ca.pem file.
Related
I have a problem dealing with an upgrade of an application doing GET request to a remote server.
First thing first : a functional example of a GET done by the old version, and as expected it works
curl -k -vvvvv https://mywebsite.com/mywonderfulwebsite/mypage.php
* Trying 192.168.0.70...
* TCP_NODELAY set
* Connected to mywebsite.com (192.168.0.70) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.0 (IN), TLS handshake, Certificate (11):
* TLSv1.0 (IN), TLS handshake, Server finished (14):
* TLSv1.0 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.0 (OUT), TLS change cipher, Client hello (1):
* TLSv1.0 (OUT), TLS handshake, Finished (20):
* TLSv1.0 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / AES128-SHA
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=MYWEBSITE.COM
* start date: Mar 24 10:20:51 2020 GMT
* expire date: Mar 24 00:00:00 2021 GMT
* issuer: CN=MYWEBSITE.COM
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /mywonderfulwebsite/mypage.php HTTP/1.1
> Host: mywebsite.com
> User-Agent: curl/7.58.0
> Accept: */*
....... and here the content of the page.....
And now from the new version, it doesn't work
curl -vvvvv https://mywebsite.com/mywonderfulwebsite/mypage.php
* Trying 192.168.0.70:443...
* TCP_NODELAY set
* Connected to mywebsite.com (192.168.0.70) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS alert, protocol version (582):
* error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
* Closing connection 0
curl: (35) error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
So I think it was from the TLS version, no problem let's force it :
curl --tlsv1.0 -vvvvv https://mywebsite.com/mywonderfulwebsite/mypage.php
* Trying 192.168.0.70:443...
* TCP_NODELAY set
* Connected to mywebsite.com (192.168.0.70) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS alert, protocol version (582):
* error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
* Closing connection 0
curl: (35) error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
and it's a fail.
I've tried adding the certificates from the remote website, and I have the same answer.
I've looked at a request using openssl client :
# openssl s_client -connect mywebsite.com:443 -tls1
CONNECTED(00000003)
139820362433856:error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available:../ssl/statem/statem_clnt.c:1112:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 7 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
And now I'm playing with versions and requests and I have no clue where I should check.
Do you know how I could troubleshoot my problem ?
Here is the solution : https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level
Late openssl package is configured to forbid the usage of TLS < 1.2 however, the first curl request shows a communication using TLS 1.0
So in debian Buster openssl package was too new
dpkg -l | grep openssl
ii openssl 1.1.1d-0+deb10u7
I didn't have to downgrade Openssl
Edit /etc/ssl/openssl.cnf
add in the beginning of the file
openssl_conf = default_conf
And this to the end of the file
[ default_conf ]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
MinProtocol = TLSv1
CipherString = DEFAULT:#SECLEVEL=1
Changing the configuration allow the usage of minimal version of TSL starting TSL 1.0 and more, so from now I can request my legacy partner.
Currently I'm testing web-application on IIS 10 using HTTP 1.1 and HTTP/2.
My test application has one endpoint (/api/test) which returns just 'true'.
I have 3 certificates:
Root CA (self-signed)
Server certificate signed by Root CA
Client certificate signed by Root CA
Root CA and Server certificate installed on Windows Server 2016, and IIS website configured for listen https://example.net:8081/ using Server certificate. Also I configure website to require client certificate (it is important for my tests, I need server/client certificates validation).
I test my app via curl, and for http1.1 all works fine.
Command:
curl.exe --http1.1 --get --url https://example.net:8081/api/test --cacert E:\ca.pem --cert E:\client.pem --key E:\client.key --cert-type PEM --verbose
Output:
* TCP_NODELAY set
* Connected to example.net port 8081 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: E:\ca.pem
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate: XXX
* SSL certificate verify ok.
> GET /api/test HTTP/1.1
> Host: example.net:8081
> User-Agent: curl/7.61.1
> Accept: */*
>
* TLSv1.2 (IN), TLS handshake, Hello request (0):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Content-Type: application/json; charset=utf-8
< Server: Kestrel
< Date: Tue, 18 Sep 2018 13:45:35 GMT
<
true* Connection #0 to host abrakadabra.cranecs.net left intact
But if I try to send request using http/2, it is failed after server certificate validation.
Command:
curl.exe --http2 --get --url https://example.net:8081/api/test --cacert E:\ca.pem --cert E:\client.pem --key E:\client.key --cert-type PEM --verbose
Output:
* TCP_NODELAY set
* Connected to example.net port 8081 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: E:\ca.pem
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate: XXX
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x1f635299100)
> GET /api/test HTTP/2
> Host: example.net:8081
> User-Agent: curl/7.61.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* HTTP/2 stream 0 was not closed cleanly: HTTP_1_1_REQUIRED (err 13)
* stopped the pause stream!
* Connection #0 to host example.net left intact
curl: (92) HTTP/2 stream 0 was not closed cleanly: HTTP_1_1_REQUIRED (err 13)
In IIS logs I see next records:
2018-09-18 13:46:00 172.32.0.193 GET /api/test - 8081 - 134.17.25.89 HTTP/1.1 curl/7.61.1 - 200 0 0 421
2018-09-18 13:55:01 172.32.0.193 GET /api/test - 8081 - 134.17.25.89 HTTP/2.0 curl/7.61.1 - 403 7 64 0
So, for http/2 it seems like client certificate absent (403.7 status code).
And finally, if I'll just change 'require client certificate' to 'ignore client certificate' on IIS site settings - http1.1 and http/2 work both.
How can I use client certificate with HTTP/2 on IIS?
After couple hours of research, I find out that the IIS 10 currently doesn't support HTTP/2 with client certificate verification.
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-not-supported
In a few cases, HTTP/2 can't be used in combination with other features. In these situations, Windows will fall back to HTTP/1.1 and continue the transaction. This may involve negotiating HTTP/1.1 during the handshake, or sending an error code to the client instructing it to retry over an HTTP/1.1 connection.
I was reconfigure my server to use nginx instead of IIS as a proxy for app, and all works fine.
I also stumbled upon this issue and after reading this information, I discovered that you need to enable "Negotiate Client Certificate" ath the binding level.
I set up a DotNet Framework 4.8 website in Server 2022 with IIS 10 and turned on require client certificates. IE worked with this fine. TLS1.3 enabled browsers did not (tried Edge and Chrome). A Wireshark capture showed the connection being reset during the handshake. After playing with editing the website bindings, I found in order for it to work, I could either enable TLS 1.3 or HTTP/2, but not both, when requiring client certificates and using a TLS1.3 enabled client.
Hopefully Microsoft will fix this for us someday
I am trying to generate the LetsEncrypt certificate files, and I am using the following commands:
./certbot-auto --config /etc/letsencrypt/configs/milhas.brau.io.conf certonly
The files are generated correctly, but in "curl" command results the message:
curl: (51) SSL: no alternative certificate subject name matches target host name 'milhasplus.brau.io'
milhas.brau.io.conf
# the domain we want to get the cert for;
# technically it's possible to have multiple of this lines, but it only worked
# with one domain for me, another one only got one cert, so I would recommend
# separate config files per domain.
domains = milhas.brau.io
# increase key size
rsa-key-size = 2048 # Or 4096
# the current closed beta (as of 2015-Nov-07) is using this server
server = https://acme-v01.api.letsencrypt.org/directory
# this address will receive renewal reminders
email = braulio#braulioti.com.br
# turn off the ncurses UI, we want this to be run as a cronjob
text = True
# authenticate by placing a file in the webroot (under .well-known/acme-challenge/)
# and then letting LE fetch it
authenticator = webroot
webroot-path = /var/www/letsencrypt/
NGINX config file
server {
listen 443 ssl default_server;
server_name milhas.brau.io;
ssl_certificate /etc/letsencrypt/live/milhas.brau.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/milhas.brau.io/privkey.pem;
location /.well-known/acme-challenge {
root /var/www/letsencrypt;
}
location / {
proxy_pass https://80.241.208.103:8084/;
}
}
curl result
$ curl -v https://milhasplus.brau.io/autenticacao/docs/termo_uso
* Trying 80.241.208.103...
* TCP_NODELAY set
* Connected to milhasplus.brau.io (80.241.208.103) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: PROFILE=SYSTEM
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=milhas.brau.io
* start date: Aug 25 10:28:56 2018 GMT
* expire date: Nov 23 10:28:56 2018 GMT
* subjectAltName does not match milhasplus.brau.io
* SSL: no alternative certificate subject name matches target host name 'milhasplus.brau.io'
* stopped the pause stream!
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (51) SSL: no alternative certificate subject name matches target host name 'milhasplus.brau.io'
Thanks
Is there a command to check the TLS version required by a host site? Right now, the only way I know to check is by adjusting the max TLS version of my browser and checking if I can still access the site. However, I suspect there is a more sophisticated way to do this.
You can check using following commands.
For TLS 1.2:
openssl s_client -connect www.google.com:443 -tls1_2
For TLS 1.1:
openssl s_client -connect www.google.com:443 -tls1_1
For TLS 1:
openssl s_client -connect www.google.com:443 -tls1
If you get the certificate chain and the handshake then the TLS version is supported. If you don't see the certificate chain, and something similar to "handshake error" then its not.
From https://maxchadwick.xyz/blog/checking-ssl-tls-version-support-of-remote-host-from-command-line:
nmap ssl-enum-ciphers
Another option for checking SSL / TLS version support is nmap. nmap is not typically installed by default, so you’ll need to manually install it. Once installed you can use the following command to check SSL / TLS version support…
nmap --script ssl-enum-ciphers -p 443 www.google.com
nmap’s ssl-enum-ciphers script will not only check SSL / TLS version support for all versions (TLS 1.0, TLS 1.1, and TLS 1.2) in one go, but will also check cipher support for each version including giving providing a grade.
I like to use curl which can report a TLS version negotiation quite nicely.
For example, this tries to connect with TLS 1.1, which the server negotiates to upgrade to 1.2:
$ curl -Iiv --tlsv1.1 https://example.com
* Trying 192.168.205.11:443...
* TCP_NODELAY set
* Connected to example.com (192.168.205.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
[...]
To forbid that the server upgrades the TLS version use the --tls-max option:
$ curl -Iiv --tlsv1.1 --tls-max 1.1 https://example.com
* Trying 192.168.205.11:443...
* TCP_NODELAY set
* Connected to example.com (192.168.205.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS alert, internal error (592):
* error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available
* Closing connection 0
curl: (35) error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available
In this case, the connection fails because the client does not offer any TLS version above 1.1, but the server does not accept any version below 1.2. If used like this, the output is very similar to the openssl_client output.
It seems the most sophisticated way is to check like this for each version:
openssl s_client -connect : -
Nmap has very convenient TLS version and ciphersuite checking NSE script. All in one, multiplatform too: https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html
I'm trying to create and provision a new EC2 instance with knife, but keep running into an SSL error:
$bundle exec knife ec2 server create
ERROR: Excon::Errors::SocketError: hostname "ec2.us-east-1b.amazonaws.com" does not match the server certificate (OpenSSL::SSL::SSLError)
I'm running this from a mac (10.7) using ruby 2.0.0p0:
$ruby -v
ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin11.4.2]
I'm fairly certain I compiled ruby with openssl support correctly. Running require 'openssl' from irb returns true. I'm using OpenSSL 1.0.1e installed via homebrew.
I also tried running knife with ruby 1.9.3-p194. That has the same result, with a slightly less helpful error message: "ERROR: Excon::Errors::SocketError: hostname does not match the server certificate (OpenSSL::SSL::SSLError)". That difference is the result of this pull request, which improved the error message: https://github.com/ruby/ruby/pull/122.
The following output from curl might be relevant:
$curl -v https://ec2.us-east-1b.amazonaws.com
* About to connect() to ec2.us-east-1b.amazonaws.com port 443 (#0)
* Trying 67.215.65.132... connected
* Connected to ec2.us-east-1b.amazonaws.com (67.215.65.132) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: serialNumber=UoFmxu6ta5ecJiIs4su2w-q-u8rxJ/d3; OU=GT55236522; OU=See www.rapidssl.com/resources/cps (c)12; OU=Domain Control Validated - RapidSSL(R); CN=*.opendns.com
* start date: 2012-08-23 10:11:50 GMT
* expire date: 2014-09-25 12:42:00 GMT
* subjectAltName does not match ec2.us-east-1b.amazonaws.com
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
* SSL peer certificate or SSH remote key was not OK
curl: (51) SSL peer certificate or SSH remote key was not OK
Is there something else I need to configure in order to successfully create an EC2 instance with knife?
In my knife.rb configuration file, I had this line:
knife[:region] = 'us-east-1b'
That worked at some point in the past, but the correct current setting is:
knife[:region] = 'us-east-1'
Removing the 'b' resolves the SSL hostname error:
$curl -v https://ec2.us-east-1.amazonaws.com
* About to connect() to ec2.us-east-1.amazonaws.com port 443 (#0)
* Trying 205.251.242.7... connected
* Connected to ec2.us-east-1.amazonaws.com (205.251.242.7) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
* subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=ec2.us-east-1.amazonaws.com
* start date: 2010-10-08 00:00:00 GMT
* expire date: 2013-10-07 23:59:59 GMT
* subjectAltName: ec2.us-east-1.amazonaws.com matched
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)09; CN=VeriSign Class 3 Secure Server CA - G2
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: ec2.us-east-1.amazonaws.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: http://aws.amazon.com/ec2
< Content-Length: 0
< Date: Sat, 16 Mar 2013 21:15:51 GMT
< Server: AmazonEC2
<
* Connection #0 to host ec2.us-east-1.amazonaws.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
When you install the chef-client on your mac book it will automatically installs the knife and dependent libraries, you dont have to do it manually. You dont have to run with bundle exec, just type knife ec2 server create, you will get the following output
** EC2 COMMANDS **
knife ec2 server list (options)
knife ec2 server delete SERVER [SERVER] (options)
knife ec2 server create (options)
knife ec2 instance data (options)
knife ec2 flavor list (options)
If you are getting this output then your knife is working properly. And also make sure your knife.rb is configured properly, if you have any problem let me know.