0

When running a handshake from a OpenSSL 0.9.8 client against OpenSSL 1.0.0 it seems that this might cause a "SSL23_GET_SERVER_HELLO:reason(1112)" error.

See Running curl with OpenSSL 0.9.8 against OpenSSL 1.0.0 server causes handshake error? for a discussion.

The solution for a client seems to be to force SSL V3 instead of V2 or V3.

Yet, I am the server in the connection running on OpenShift with Apache. I do not have access to ssl.conf and the Apache logs as it seems.

Is there any workaround for me to change the configuration in OpenShift or to bypass the problem?

Community
  • 1
  • 1
Christopher Oezbek
  • 23,994
  • 6
  • 61
  • 85

1 Answers1

1

I found the answer in the OpenShift bug tracker:

On further exploration, there doesn't appear to be a mechanism which allows the mod_rewrite based Apache front-end to handle SNI on the primary application address (name-domain.rhcloud.com). SNI is handled properly with aliases that supply their own SSL certificates.

Result: It is not possible to receive SSL connections by clients using strict SNI when using *.rhcloud.com and not a custom domain with own SSL cert.

Christopher Oezbek
  • 23,994
  • 6
  • 61
  • 85