Thomas,This is very strange, since you are clearly receiving data via SSL, it does not make any sense that SSL is not working. Maybe this HTTP server reacts differently when using TLS v1.2 instead of an older version? It should never be allowing the connection and sending back a "400 Bad Request" in that case, as "400 Bad Request" is an HTTP response, not an SSL one, and it is using the SSL connection to send it, which it should not do if it does not like your TLS options. But, who knows? Perhaps this was written by someone who doesn't understand that.
You could try disabling the newer SSL versions in version 1.32 by coding this before any HTTP requests:
https_init(*blanks: *off: *on: *on: *off: *off);This enables SSLv3 and TLS v1.0, but disables SSLv2, TLSv1.1 and TLSv1.2. Those should be the same SSL options that were available in the older HTTPAPI.
There were two other things that changed in COMMSSLR4 between version 1.25 and 1.32.
1) We enabled Server Name Indication (SNI) in version 1.26 with the GSK_SSL_EXTN_SERVERNAME_REQUEST option.
2) We enabled timeouts with GSK_IBMI_READ_TIMEOUT in version 1.31I do not know any reason that these would change any behavior, but if setting https_init() to turn off the new TLS versions does not solve the problem, you could try commenting out the code that sets those two options to determine if one of those is affecting the "400" error.
In any case, there is something very unusual happening because SSL/TLS is clearly working, the connection is received and you are receiving data over the encrypted connection. I can't understand why it can send/receive data over the connection if there is an SSL/TLS problem.
On 10/8/2016 3:35 AM, Thomas Raddatz wrote:
Hi Scott, I do not understand, why the same program (my stripped down test program and the original program in our production environment) work with HTTPAPI 1.25 and do not work with 1.26+. It is only the version of HTTPAPI that makes the difference. For what I can see in the debug logs, the headers and the xml message are the same (snippet from Example16B_Error_1.32.log): do_oper(POST): entered There are 0 cookies in the cache POST /core33/services/FooXmlTransport HTTP/1.1 Host: e-sourcing.qa.foo-baa.com User-Agent: http-api/1.xx Content-Type: text/xml SOAPAction: Content-Length: 358 senddoc(): entered <?xml version="1.0" encoding="UTF-8"?><SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:impl="http://foo.ws.util.common"><SOAP:Body><impl:transportXml><impl:request><impl:clientExternalId>CL 6300 </impl:clientExternalId><impl:firma>1</impl:firma><impl:xml></impl:xml></impl:request></impl:transportXml></SOAP:Body></SOAP:Envelope> recvresp(): entered These lines (above) are identical with the related lines in Example16B_OK_1.25.log. But 1.32 ends with a 400 error and 1.25 runs just fine. So what am I missing? I just had another idea right now. I took the 1.32 library and renamed GSKSSL_H to GSKSSL_32, updated COMMSSLR4 and renamed it to COMMSSLR4N. Then I copied GSKSSL_H and COMMSSLR4 from library 1.25 to the 1.32 library. I renamed GSKSSL_H to GSKSSL_25, updated COMMSSLR4 and renamed it to COMMSSLR4A. So I ended up with the following source members in library 1.32: GSKSSL_32 COMMSSLR4N GSKSSL_25 COMMSSLR4A Now I was able to compile HTTPAPI with the COMMSSLR4 module of version 1.25 or version 1.32 in library 1.32 just by copying either COMMSSLR4N or COMMSSLR4A to COMMSSLR4 before calling the INSTALL program. I started the debugger before calling my test program to check the version of module COMMSSLR4. It had to include either GSKSSL_32 or GSKSSL_25. The result was: HTTAPAI 1.32 compiled with COMMSSLR4 1.32 ends with the 400 error. HTTAPAI 1.32 compiled with COMMSSLR4 1.25 runs just fine. So the problem is in module COMMSSLR4, which make be believe, that it might be a configuration problem on our IBM i. What do you think about that? Thomas. Am 08.10.2016 um 00:20 schrieb Scott Klement:Thomas, I don't understand what you are looking for, here. SSL is clearly working in all of these situations, if it were not, you could not get back a "400 Bad Request" message, as that message is sent using SSL. In all cases, it is connecting and sending data successfully over SSL. The message "400 Bad Request" does not mean that SSL is not working, it means that the server doesn't understand your request. Possibly it is expecting the XML data, or the URL, or one of the HTTP headers to be different. It does not say which one. But it has nothing to do with SSL. -SK On 10/7/2016 4:14 AM, Thomas Raddatz wrote:Hi folks, Really no ideas? I do not understand the problem. Here is what I fugured out so far: a) HTTPAPI works fine up to and including version 1.25 (tested with 1.25beta2). b) I always get a http 400 " Your browser sent a request that this server could not understand." error starting with 1.26. c) Debugging 1.25, 1.26 and 1.32 revealed that all versions use TLS 1.2. At least gsk_attribute_get_enum(GSK_PROTOCOL_USED) returns 596 for all tested versions of HTTPAPI. I attached some more log files from stripped down test programs based on Example16. Regards, Thomas. -----Ursprüngliche Nachricht----- Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Thomas Raddatz Gesendet: Dienstag, 4. Oktober 2016 09:18 An: ftpapi@xxxxxxxxxxxxxxxxxxxxxx Betreff: Cannot get SSL working on 7.2 Hi, I tried to update HTTPAPI from 1.24beta11 to 1.32, but I cannot get SSL connections to work. The problem is that the server returns a http 400 error (Your browser sent a request that this server could not understand.) instead of a soap message. I already tried to enable everything from SSL v2 to TLS v1.2 as well as disabling the latest TLS versions 1.1 and 1.2. No success so far. I am stuck. I am almost sure, that the server uses TLS v1.2, because that is what the certificate shows (Firefox SSL Info): "Verbindung verschlüsselt (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128-Bit-Schlüssel, TLS 1.2)." On the other hand I wonder how HTTPAPI 1.24 could establish a TLS 1.2 connection. We are on 7.2 and the relevant system values are set to: QSSLPCL: *OPSYS QSSLCSLCTL: *OPSYS QSSLCSL: lists 29 cipher suites I am sure I am missing something obvious. Your help is greatly appreciated. Regards, Thomas. -- IMPORTANT NOTICE: This email is confidential, may be legally privileged, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. -- IMPORTANT NOTICE: This email is confidential, may be legally privileged, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. ----------------------------------------------------------------------- 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 ---------------------------------------------------------------------------------------------------------------------------------------------- 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 -----------------------------------------------------------------------