Dave - Thanks much.
> Either there's a bug somewhere or you are being attacked (MitM'ed). Unlikely I am being MitM'ed -- the connection is over a VPN. (Why TLS when there is already a VPN in place? I am testing TLS software and the VPN is a fact of life and my only client to server link. > Do you mean the server, running 1.0.1h on Win7, produced this error message, or some client talking *to* such a server produced the error? Statement was kind of ambiguous, wasn't it? The server, which is OpenSSL 1.0.1h 5 Jun 2014, produced this message, when the client attempted to connect. The client is application software that uses the IBM GSK crypto library on z/OS. The error message at the client end is Error code 9 returned from GSK function gsk_secure_socket_init(): Cryptographic processing error. It is my code that produces that exact message, but the 9 comes back from the indicated method and the text comes from a system function, gsk_strerror(9). The documentation says 9 Cryptographic processing error. Explanation: An error is detected by a cryptographic function. This error may also occur if key sizes that are non-FIPS are used during an SSL handshake while operating in FIPS mode. User response: If the error occurred while executing in FIPS mode, check that only FIPS key sizes are used. Collect a System SSL trace containing the error and then contact your service representative. I can connect between the client and the server using the set of parameters under test. They negotiate TLSV1.1 and what you call DHE-RSA-AES256-SHA and GSK calls Cipher Suite 39 - SSL V3.0 AES SHA-1(ephemeral Diffie-Hellman) RSA. It works provided I do not turn on FIPS 140-2 mode. If I turn on FIPS 140-2 mode with rc = gsk_fips_state_set(GSK_FIPS_STATE_ON); and use otherwise identical parameters then this error occurs. (Cipher Suite 39 is a valid FIPS 140-2 cipher suite, according to the IBM GSK documentation.) I don't think that an s_client test would be terribly informative, seeing as I can connect with the actual client software. Back to you ... Charles -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Wednesday, November 19, 2014 2:20 PM To: openssl-users@openssl.org Subject: RE: SSL alert number 51 > From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills > Sent: Wednesday, November 19, 2014 14:08 > 10280:error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error:.\ssl\s3_pkt.c:1275:SSL alert number 51 http://tools.ietf.org/html/rfc5246.html#section-7.2 decrypt_error A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. This message is always fatal. Either there's a bug somewhere or you are being attacked (MitM'ed). > OpenSSL 1.01h is the server, running on Windows 7 Pro 64 bit. Do you mean the server, running 1.0.1h on Win7, produced this error message, or some client talking *to* such a server produced the error? In either case, what is in the error output or log of the opposite peer? If you try to connect s_client to the server, or the client to s_server, respectively, does it work or what error info does it give you? ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
