[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SSL problem



Scott,

Thanks for the info.

Yes, I know that the GSK error messages were sorted at a later version,
but for the time being, this Customer's system wasn't broke, so I didn't
fix it :-)). Just needed to check that first.

The important info from you is the SSL process (3) below. That's what I
am missing from my understanding - the exact sequence of events when a
connection is being set up. This is the useful bit so I don't need to go
delving into their DCM. This remote host just doesn't go down for any
length of time. It's the main UK Banking system. The slow response of
the host is possible but unlikely over a period. I will concentrate on
the path to Host to see if its changed.

Many thanks, nice to hear from you again.

Regards
 
Ian Patterson

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
Klement
Sent: 06 May 2008 18:39
To: HTTPAPI and FTPAPI Projects
Subject: Re: SSL problem


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
-----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------