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

Re: HTTPAPI GSKIT Invalid Handle



Hi Shannon,

Something is messed up in the Digital Certificate Manager.  Apparently, 
the "default profile" (If that's the right term) of the *system 
certificate store is messed up somehow.

All you've done (by passing a profile to https_init) is that you've 
specified a different profile in the certificate store, instead of using 
the default one.  So if the default one is corrupted, and the one you're 
using is not, you're able to circumvent the problem.  (Until you need to 
use the default profile for something else, anyway!)


Shannon ODonnell wrote:
> Hi Scott,
> 
> Don't know WHY this made a difference, but by putting the name of the
> certificate into the call to https_init(), the process worked correctly.
> The documentation of that API in the code says that *BLANKS will use the
> default certificate, but it didn't.
> 
> FYI
> 
> Shannon O'Donnell
> 
> 
>  
>  
> 
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Shannon ODonnell
> Sent: Monday, April 28, 2008 10:00 AM
> To: 'HTTPAPI and FTPAPI Projects'
> Subject: HTTPAPI GSKIT Invalid Handle
> 
> I have been asked to look at a problem with HTTPAPI and GSKit a friend's
> client is having. 
> 
>  
> 
> I know very little about the entire setup except that they use HTTPAPI and
> GSKit as part of their routine to get shipping rates from UPS.
> 
>  
> 
> Apparently everything has been working great until a few days ago when they
> had to renew and reinstall their SSL certificate.  
> 
> After they did that, now they get the error "(GSKit) Invalid Handle"
> returned when the program calls the http_url_post_xml procedure.
> 
> 
> There have been no programming changes, that they know of, only the
> installation of this new certificate.  
> 
>  
> 
> The only thing I can see, upon an initial look at the code, is that they are
> calling the https_init() routine with no name (i.e., *blanks) in the
> certificate name.  
> 
> However, when I look at the HTTPAPI code and comments for this procedure, I
> see a comment that passing blanks will take the default certificate anyway
> 
> And that's also what they have always done so I don't know why passing
> blanks to it now would be a problem.
> 
>  
> 
> This is a V5R3 system, if that makes a difference.
> 
>  
> 
> I would like to help them resolve this, if possible, but honestly, other
> than making sure the certificate was installed correctly (appears to be) and
> reviewing the code that calls
> 
> HTTPAPI procedures (look fine to me) I'm not sure what else to look at.
> 
>  
> 
> If it helps, I have a sample of the XML that they are passing to UPS.
> 
>  
> 
> Any ideas of things to look for/check for would be appreciated.
> 
>  
> 
> Shannon O'Donnell
> 
>  
> 
>  
> 
> 
> -----------------------------------------------------------------------
> 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
-----------------------------------------------------------------------