Ignore my previous comment. It was configuration issue, which creates faults of traffic server and core files. It works now.
Thanks anyone for help. 2015-05-06 18:05 GMT+02:00 Jiří Podhorský <podhorsky....@gmail.com>: > I tried to add parameters --no-check-certificate --trust-server-names to > wget and no change. Hmm, but if client didn't send the client hello packet, > (according to wireshark) server can't send server hello packet and the > certificate. So, in this step the certificate shouldn't be verified, > because client don't have server's certificate and server don't know about > address which client want to use. > > Can be this caused by anything else? > > > 2015-05-06 16:43 GMT+02:00 Leif Hedstrom <zw...@apache.org>: > >> >> > On May 6, 2015, at 5:16 AM, Jiří Podhorský <podhorsky....@gmail.com> >> wrote: >> > >> > Ok, I redirected port 443 to proxy via iptables. Now the message connect >> > disapear. I can see in wireshark the connection is redirected correctly. >> > But when I try to connect via https: >> > >> > wget -4 https://www.google.com >> > --2015-05-06 13:12:07-- https://www.google.com/ >> > Resolving www.google.com (www.google.com)... 173.194.116.243, >> > 173.194.116.244, 173.194.116.240, ... >> > Connecting to www.google.com (www.google.com)|173.194.116.243|:443... >> > connected. >> > OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert >> > handshake failure >> > Unable to establish SSL connection. >> >> >> You can’t do that. That would be a man-in-the-middle attack against TLS. >> If you were to try to do intercepting proxying of TLS, you would also need >> to generate certificates for all sites that you expect to proxy. E.g. a >> certificate for www.google.com. >> >> — Leif >> >> >
