> From: owner-openssl-us...@openssl.org On Behalf Of Leonardo Laface de
Almeida
> Sent: Tuesday, 11 September, 2012 10:08
> To: openssl-users@openssl.org
> For any SSL connection, you have to assure that:
>
> 1- The cpu's can reach each other (the hostname
> "test.mydomain.com" must be also resolved). You may use ping,
> HTTP, FTP to check it out;
More exactly, the TCP stacks must be able to connect.
That requires slightly more than IP reachability --
not much more, but enough to be a problem in rare cases.
But "CONNECTED(fd)" from s_client means they *did* TCP
connect, so that's not the problem here.
> 2- Certificates or CA chain from each endpoint must be
> inserted in the opposite side as trust cert;
A problem here would cause a handshake error not a hang.
> 3- The both sides must have at least one cipher in common;
A problem here would cause a handshake error not a hang.
> 4- No NAT or Firewall is filtering the messages.
>
Yes, or possibly other middlebox, see below.
> I have never made a connection by openssl command line, so, I
> can't tell you how to check it out .
>
> I advice you to use some sniffer in at least one side, then
> you can reach the error, eg. where handshake is failuring,
> get the error code, etc... Using this you might be able to
> solve your problemm.
>
Maybe both sides, see below.
> As I saw your logs, perhaps one side doesn't trust in the
> opposite cert received. That may happen for many reasons.
> I've already got some cases that the hostname (in your case
> "test.mydomain.com") must match with certificate common name (CN).
>
According to the log posted, his host is www.mydomain.com and
the cert is for *.mydomain.com . That is a valid wildcard match,
and should be acceptable to any conforming client. But openssl
library and s_client doesn't do hostname matching at all.
(*Apps* using openssl normally should, and at least some do.)
I don't know if "mydomain" is supposedly real or munged for posting.
mydomain.com is a real company and test.mydomain.com doesn't
resolve publicly and the cert chain used for {www.,}mydomain.com
publicly is wholly different from the OP's log.
OP's s_client fails to verify the received chain because it
(apparently) doesn't have the ValiCert root in its truststore.
Official openssl does not distribute any default trusted roots,
although custom packages of it may, as may apps using it.
OP probably didn't install a default truststore (or possibly
is using a build that has the default truststore wrong).
But failure to verify should cause a real app to reject the
connection, and s_client as a test tool overrides the verify
error and continues. Neither of these is a hang.
In the other direction, s_client doesn't do client authentication
and send a client cert unless explicitly specified, which the OP
didn't. If the server wants client-auth and client doesn't provide
it or provides a cert (chain) which server doesn't trust, that will
give a handshake error, not a hang.
> -----Mensagem original-----
> De: owner-openssl-us...@openssl.org
> [mailto:owner-openssl-us...@openssl.org] Em nome de Supratik Goswami
> Enviada em: terça-feira, 11 de setembro de 2012 10:15
> Para: openssl-users@openssl.org
> Assunto: Re: HTTPS connection hangs during SSL handshake
>
> Is there no one in the community who can help me to find the cause of
> the problem ?
>
> On Tue, Sep 4, 2012 at 7:21 PM, Supratik Goswami
> <supratiksek...@gmail.com> wrote:
> > I am using OpenSSL version : openssl-1.0.0j in our production.
> >
> > I am facing a strange problem where the SSL connection simply hangs
> > during initial handshake when requested from our office IP address.
> > When I run the same command from another IP address it works fine.
> >
> > From office IP (Unsuccessful connection):
> >
> > [root@gateway ]# openssl s_client -connect test.mydomain.com:443
> > CONNECTED(00000003)
> >
Use s_client with at least -state and preferably -debug or -msg
(you don't need both) to see how far it's getting in the handshake.
If you receive some handshake messages but not all, it practically
must be the server; talk to the server operator(s). It would be
unusual, but not impossible, for the server to mishandle connections
from one IP while it works for another. If you receive no message
at all, it might be server (try them) or it might be network
weirdness as (Mr?) de Almeida suggests; try a sniffer on your client
machine or near it (same LAN), and if that looks okay also try one
on or near the server (you may need server operator(s) to do that).
For Windows or Mac, I recommend www.wireshark.org . Very capable,
easy to install and use, well maintained. I don't know an equally
good solution for Linux, but there may be one, or at minimum you can
capture with tcpdump and if it's anything more complicated than
no-response you can copy the capture and decode with wireshark.
One possibility -- some servers want to lookup in DNS the address
of the client who connects to them (called reverse DNS or rDNS).
If this is done synchronously before the SSL handshake, and rDNS
is set-up correctly for client#2 but not client#1, then this could
cause the handshake for client#1 to stall. But even in worst case,
(r)DNS should timeout within a minute or so, and then the server
should either continue or reject the connection (disconnect).
> >
> > From a different IP (Successful connection):
> >
> > ubuntu@ip-10-0-0-10 (Development):~$ openssl s_client -connect
> > test.mydomain.com:443
> > CONNECTED(00000003)
<snip: normal for unverified cert chain>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
