Re: SSL problem

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Ian,

1) Correct, the gsk_handle stuff is a side effect of the "connection 
refused" message.  It's worth noting that this side effect was fixed in 
HTTPAPI version 1.18.  (The current version is 1.23).  You're a little 
behind the times, my friend.

2) The important bit is the 'Connection refused' error.  That's what's 
preventing the connection from working.

3) This is utterly unrelated to SSL certificates.  The SSL process works 
something like this:  Connect, Exchange Certificates, Start encryption, 
then do the HTTP protocol.   Since it's failing on the 'connect' 
operation, there's no possibility that the error is related to SSL 
certificates!  It never reached the point where it tried to exchange them...

4) 'Connection Refused' is an error message sent from the computer 
hosting the HTTP server back to HTTPAPI.  It's a standard part of the 
TCP protocol, and it means 'There's no server program listening on the 
port you've tried to connect to, so I have to refuse your connection.'


Here's my list of possibilities:

a)  The HTTP server you're connecting to is down.  90% of the time, this 
is the cause of a 'connection refused' error.

b)  A firewall is blocking the connection.  6% of the time.  It's 
unusual for a firewall to send back an 'connection refused' error -- 
firewalls usually just discard the network packets, which eventually 
causes a 'timeout' error.  However there are a rare firewalls which will 
send back "connection refused" in order to prevent the client program 
from sitting and waiting for the timeout to occur.

c)  The HTTP server is overloaded.  4% of the time.  It's receiving more 
connections than it can handle, and therefore has to refuse some of them.



ian wrote:
> An SSL problem has just occurred in a system that has been running OK
> for 18 months, connecting to the same (only) host.
> 
> Debug info:
> 
> HTTPAPI Ver 1.16 released 2006-05-07
> 
> New iconv() objects set, ASCII=819. EBCDIC=0
> https_init(): entered
> ------------------------------------------------------------------------
> -------------
> Dump of local-side certificate information:
> ------------------------------------------------------------------------
> -------------
> http_url_get(): entered
> http_persist_open(): entered
> http_long_ParseURL(): entered
> SetError() #6: connect(): A remote host refused an attempted connect
> operation.
> (GSKit) The socket descriptor specified within the gsk_handle is not
> valid.
> ssl_error(6016): (GSKit) The socket descriptor specified within the
> gsk_handle is not valid.
> SetError() #30: SSL Handshake: (GSKit) The socket descriptor specified
> within the gsk_handle is
> ------------------------------------------------------------------------
> -------------
> Dump of server-side certificate information:
> ------------------------------------------------------------------------
> -------------
> Cert Validation Code = 0=
> 
> Questions:
> Is the GSKit socket descriptor error just a knock on effect from the
> original host refused error ? (i.e. can be ignored here).
> Assuming that this connection, certs etc have all worked OK for a long
> time. What possible causes may create this error ?
> I am sure that the SSL certs in the DCM are OK.
> 
> My possibles are:
> 1. Firewall / router issue.
> Is it possible that this may be a routing/router problem - i.e. the
> 'host' rejecting the connection is not actually the host we are trying
> to connect to ?
> 2. SSL cert in DCM has become corrupted. (Unlikely in my experience).
> 
> Many thanks. 
> 
> 
> Regards
>  
> Ian Patterson
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------