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

Re: Certificate change causing problems



   Scott,
   We do have IBM involved and they are confirming some of the things you
   mentioned below.  They have suggested a few PTFs that we have gone
   ahead and installed.  Ultimately though, they have confirmed after
   doing some traces that the server side is indeed transmitting a
   malformed response which is greater than 16384.  IBM offered a couple
   of possible reasons for this, including perhaps having an unusually
   large number of trusted CAs that is being returned to us.  IBM says
   the 16384 limit is imposed by RFC 2246 and that the server side is
   breaking that limit so the changes have to occur on that side, either
   by reducing the number of trusted CAs they are returning to us or by
   some other means.
   I believe the server side knows they are breaking this limit based on
   recent communications with them.  They indicate it is hard-coded to
   behave this way on their side and can't be changed.  I'm hoping we can
   persuade them otherwise, but I'm not convinced.

   On Wed, Feb 9, 2011 at 3:51 PM, Scott Klement <[1]sk@xxxxxxxxxxxxxxxx>
   wrote:

     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:
     [2]http://www.scottklement.com/mailman/listinfo/ftpapi
     -------------------------------------------------------------------
     ----

References

   1. mailto:sk@xxxxxxxxxxxxxxxx
   2. 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
-----------------------------------------------------------------------