Re: Certificate change causing problems

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Jeff,

On 2/9/2011 9:58 AM, Jeff Nickles wrote:
>
>     A year ago, we experienced problems in HTTPAPI after we were put in a
>     position where we had to change our certificate from a class 1 to a
>     class 3.  After installing the new certificate and making no other
>     changes to the application, we received this error:
>     "(GSKit) Peer not recognized or badly formatted message received".
>     We were not able to get past this issue.  Eventually, we were given a
>     reprieve and the old class 1 certificate was renewed and the problem
>     went away.

This error is not occurring inside HTTPAPI, but rather is occurring 
inside the operating system's SSL functions.  (i.e. it's happening 
inside OS/400.)

Obviously, HTTPAPI calls those routines in the operating system.  But 
the code that's giving you the error is not part of HTTPAPI.


>     Now, we have little choice but to go to the class 3 cert and the error
>     above is again rearing its ugly head.  Unfortunately, I'm a novice
>     when it comes to certificates so any help is greatly appreciated.

Install the latest PTFs for your system?  (Both cume and group.)  Does 
that help?  If not, we're left with two possibilities:

1) You've configured something wrong.  (No idea what, though.)

2) You're using a type of certificate that IBM doesn't support in it's 
SSL code.

About the only way that *I* can fix that is to change HTTPAPI to use a 
different SSL suite (instead of the one built-in to OS/400).  That would 
not be an easy task, I'm afraid.


>     Here's what we determined last year during our analysis and what we've
>     learned this time.  Below is a log as well of a recent test.
>     We determined last time that gsk_secure_soc_read() is returning the
>     410 error above.  This same error is being returned this time.  This
>     is occurring after posting the initial request chain, but before
>     getting to post the application data.

So it's occurring the first time you try to communicate anything over 
SSL.  No surprise there!


> The post of the initial request chain does not return any error. Some
> traces have been performed and we've been told that the amount of
> data being returned after our initial request chain post is greater
> than 16384.  Is this a limit imposed by GSKit or HTTPAPI?  Can it be
> changed through a parameter or some other setting or am I even
> thinking of this limit the correct way?

As best as I can tell, you are talking about the internal structure of 
an SSL record??  Is that what you're referring to?

In the internals of TLS/SSL, each encrypted "record" of data can only be 
16384 bytes long.  This imposes no limitations on the amount of data you 
can send, however...   if the sent data is longer than 16384, it's split 
into multiple 16384 chunks, and put back together on the other side. 
That's all done internally, inside the SSL/TLS code provided by IBM (and 
whomever wrote the SSL code on the server side.)

It sounds to me as if your system is sending the request successfully, 
but the remote system is creating a malformed TLS/SSL record (larger 
than 16384) in response?   But if that's the case, it shouldn't be able 
to communicate with anyone, since it's violating the TLS/SSL standards!

But, again, this is internal... inside the SSL code of OS/400.  It's not 
something I have any control over, you're going to need to ask IBM for 
help.


> I ask this because with the class 1 cert style, this error doesn't
> occur.  I guess I'm struggling to understand why a simple cert change
> would cause something like this.

I agree with you.  I don't see why changing a certificate would cause 
this... especially since you're getting past the certificate exchange 
without any errors!

...but the best guess I can come up with is this:   The certificate 
might be affecting the way the cryptography is done.  And a bug in the 
crypto routines might cause the size of the record to exceed 16384, 
under a particular condition?

At any rate, again, it's internal to the SSL routines.  Not part of HTTPAPI!


> We do use application specific certs and the new cert has been
> associate with our application ID in the DCM.  We've tried
> initializing SSL 2.0, SSL 3.0 and TLS 1.0 in HTTPS_INIT, each in
> turn; none of them work.

Not sure what you mean by "application specific certs".  Do you mean 
client-side certificates or CA certificates?  Is it your certificate 
that's changing from class I to class III?  Or is it the server's 
certificate?

Client-side certificates are rather rare in HTTP.  (But, IBM should 
still provide proper support for them!)

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