Closed clayton256 closed 10 years ago
@danimo Sort of. I am getting an A- on SSL labs. The command you provided returns an error for me. says unknow option where you have yourhost.com the second time .
EDIT:OpenSSL on Mac 10.9 and Ubuntu 12.04, 14.04
@danimo same problem as @joubin using ubuntu openssl to test.
@danimo Add me to the list too. Qualys SSL's test gives me an A+, no errors. Your openssl s_client command only gives one warning, but that's just related to closing the session: SSL3 alert write:warning:close notify
Clients for Windows and IOS devices work flawlessly.
Certificate is purchased, not self-signed.
Apache doesn't log the mac client connection attempt (ssl_connect_log, ssl_request_log, ssl_error_log all remain silent), but I do see some tcp back and forth with tcpdump (from the server).
Server: Apache/2.4.9 (Fedora) OpenSSL/1.0.1e-fips PHP/5.5.12 mod_perl/2.0.9-dev Perl/v5.18.2
Edit:
I cranked up the server logging to debug, here's what Apache is reporting:
[Tue Jun 03 17:04:06.929538 2014] [ssl:info] [pid 933] [client x.x.x.x:50582] AH01964: Connection to child 7 established (server xxxx.xxxx.xxx:443)
[Tue Jun 03 17:04:06.930115 2014] [ssl:debug] [pid 933] ssl_engine_kernel.c(1929): [client x,x,x,x:50582] AH02044: No matching SSL virtual host for servername xxxx.xxxx.xxx found (using default/first virtual host)
[Tue Jun 03 17:04:07.449573 2014] [ssl:debug] [pid 933] ssl_engine_io.c(1212): (70014)End of file found: [client x.x.x.x:50582] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[Tue Jun 03 17:04:07.449700 2014] [ssl:info] [pid 933] [client x.x.x.x:50582] AH01998: Connection closed to child 7 with abortive shutdown (server xxxx.xxxx.xxx:443)
@danimo
Here is wireshark's capture of the communication:
7 4.028764 client -> server TCP 78 50855 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=1413293448 TSecr=0 SACK_PERM=1
8 4.028945 server -> client TCP 74 https > 50855 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=273364807 TSecr=1413293448 WS=128
9 4.060303 client -> server TCP 66 50855 > https [ACK] Seq=1 Ack=1 Win=131760 Len=0 TSval=1413293473 TSecr=273364807
10 4.068103 client -> server SSL 192 Client Hello
11 4.068196 server -> client TCP 66 https > 50855 [ACK] Seq=1 Ack=127 Win=29056 Len=0 TSval=273364846 TSecr=1413293480
16 4.576222 server -> client TLSv1 2962 Alert (Level: Warning, Description: Unrecognized Name), Server Hello
17 4.576554 server -> client TLSv1 1266 Certificate
18 4.576852 server -> client TLSv1 629 Server Key Exchange
19 4.606028 client -> server TCP 66 50855 > https [ACK] Seq=127 Ack=2897 Win=128864 Len=0 TSval=1413293876 TSecr=273365354
20 4.608678 client -> server TCP 66 50855 > https [ACK] Seq=127 Ack=4097 Win=127664 Len=0 TSval=1413293876 TSecr=273365355
21 4.608888 client -> server TCP 66 [TCP Window Update] 50855 > https [ACK] Seq=127 Ack=4097 Win=131072 Len=0 TSval=1413293876 TSecr=273365355
22 4.609460 client -> server TCP 66 50855 > https [FIN, ACK] Seq=127 Ack=4097 Win=131072 Len=0 TSval=1413293876 TSecr=273365355
23 4.609704 server -> client TCP 66 https > 50855 [FIN, ACK] Seq=4660 Ack=128 Win=29056 Len=0 TSval=273365388 TSecr=1413293876
24 4.610526 client -> server TCP 60 50855 > https [RST] Seq=127 Win=0 Len=0
25 4.610609 server -> client ICMP 82 Destination unreachable (Host administratively prohibited)
42 4.920583 server -> client TCP 629 [TCP Retransmission] https > 50855 [FIN, PSH, ACK] Seq=4097 Ack=128 Win=29056 Len=563 TSval=273365699 TSecr=1413293876[Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)]
43 4.947994 client -> server TCP 77 50855 > https [RST] Seq=128 Win=0 Len=23
I can only assume that that "Unrecognized Name" error is because the server is set up to host multiple domains. (The SSL cert is a UCC type that has other alternate names)
Otherwise, the only other thing I can think of that is causing the client to drop the connection is the piggybacking of the intermediate cert that gets sent along with the server public cert?
Here's more detail:
Client HELLO asks for these Cipher Suites:
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x009a)
Cipher Suite: TLS_DHE_DSS_WITH_SEED_CBC_SHA (0x0099)
Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014)
Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011)
Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
and correctly specifies the FQDN of the server in the HTTP request.
Server HELLO replies with an Alert warning: Unrecognized Name, and then specifies this supported Cipher Suite, which is the first one the client asks for:
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
The server then sends the certificate contents which include both the server's public key, and the intermediate certificate owned by the signing cert company (Starfieldtech). This second cert is needed to complete the chain back to the trusted certs that the client would have on file on the local workstation. Note that the common name in the server's cert matches the FQDN the client asked the server for.
The client then responds with a TCP FIN thus starting the breakdown of the communication.
@danimo
I got the client to work when I specified the server name in the Apache ssl configuration file:
ServerName xxxx.xxxx.xxx:443
This breaks the server's ability to serve other domains securely with the UCC cert, so I had to disable it, but I think this is your smoking gun: The mac client software is incorrectly honoring that "Unrecognized Name" warning as being an error instead.
@zestysoft 's advice is right on the money. Setting the ServerName in /etc/apache2/sites-available/000-default.conf
fixed it for me. (I should learn to read threads backwards.)
Same here: I had ServerName myServer
in /etc/apache2/apache2.conf
already, but Mac OS added the .local suffix to host names, so adding ServerName myServer.local
and running service apache2 reload
did the trick.
Hello All,
just in case it's helpful to another reader of this thread, I bumped into a similar issue, an SSL SNI handshake error.
My SSL handshake error manifested as follows:
{code} $ git clone https://GIT-HOST/GIT-PROJECT.git Cloning into 'GIT-PROJECT'... fatal: unable to access 'https://GIT-HOST/GIT-PROJECT.git/': SSL peer handshake failed, the server most likely requires a client certificate to connect {code}
My local Mac development environment:
I resolved the SSL SNI handshake error as follows:
1/ Upgraded openssl resources for Mac Port
{code} sudo pip install ndg-httpsclient pyasn1 sudo pip install ndg-httpsclient pyasn1 --upgrade {code}
2/ Upgraded Apple XCode developers tools
e.g.
{code} xcode-select --install {code}
3/ Update Git client configuration
Edit file $HOME/.gitconfig and change "sslvertify" from "false" to "true"
From ...
{code} ...
[http] postBuffer = 209715200 sslverify = false
.... {code}
To ...
{code} ...
[http] postBuffer = 209715200 sslverify = true
.... {code}
Some helpful references:
How to upgrade OpenSSL in OS X? ** http://apple.stackexchange.com/questions/126830/how-to-upgrade-openssl-in-os-x
Command Line Tools bash (git) not working - macOS Sierra final release candidate ** http://stackoverflow.com/questions/39484218/command-line-tools-bash-git-not-working-macos-sierra-final-release-candidate
kennethreitz requests - https GET request fails with "handshake failure" #2022 ** https://github.com/kennethreitz/requests/issues/2022#issuecomment-133204955
Regards,
Tim
email: telcik@gmail.com
Instead of wireshark, here is a simpler way to reveal this issue if you have openssl...
$ openssl s_client -servername domain.com -connect domain.com:443 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL3 alert read:warning:unrecognized name
SSL_connect:SSLv3 read server hello A
The OSX client used to connect but I don't know when it stopped working. It now fails to connect to an owncloud install on my web hosting site (bluehost.com). I get error "SSL handshake failed". The client log shows: 06-19 11:08:54:414 ownCloudInfo Network Error: 6 06-19 11:08:54:414 status.php returns: "" 6 Reply: QNetworkReplyImpl(0x1015b3be0) 06-19 11:08:54:414 No proper answer on "https://box282.bluehost.com/~m/owncloud/status.php/status.php"
If I run curl on that url, it get, what looks like a valid OC response: $curl -3 https://box282.bluehost.com/~m/owncloud/status.php {"installed":"true","version":"5.0.12","versionstring":"5.0.7","edition":""}$
The linux (Ubuntu 13.04) client works fine.
I don't see anything interesting in the server logs.
owncloud 5.0.7 OSX clients 1.3.0beta3 and 1.2.5 PHP 5.4.15 Apache 2.2.24 openssh 5.3p1