title: grpc C++: default Ssl ChannelCredentials client side calls fail
body: <p>Using the grpc version 1.38.0, compiled on CentOS 7 from sources with gcc version 9.4.0 and cmake version 3.19.6 (with all the cmake dependencies set to &quot;module&quot;), the following code taken from the <a href="https://grpc.io/docs/guides/auth/" rel="nofollow noreferrer">grpc documentation site</a>:</p>
  <pre><code>auto channel_creds = grpc::SslCredentials(grpc::SslCredentialsOptions());
  auto channel = grpc::CreateChannel(server_name, channel_creds);
  </code></pre>
  <p>compiles, links, runs, does not coredump but the respective grpc calls executed against that channel all fail with the following error message:</p>
  <pre><code>E0816 17:49:03.236686130   14443 ssl_transport_security.cc:1468] Handshake failed with fatal error SSL_ERROR_SSL: error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER.
  </code></pre>
  <p>Since the referenced above google's documentation sample that implements</p>
  <blockquote>
  <p>the simplest authentication scenario, where a client just wants to authenticate the server and encrypt all data</p>
  </blockquote>
  <p>is taken to be complete, the respective grpc c++ server was bound to a needed port via the <code>grpc::InsecureServerCredentials()</code> option.</p>
  <p>Clearly, either the sample code is not complete or some other instructions on how to implement &quot;the simplest authentication scenario, where a client just wants to authenticate the server and encrypt all data&quot; are missing.</p>
  <p>Question: could someone please provide a complete c++ code that must be written on both the grpc c++ client side and the grpc c++ server side so that the much advertised &quot;simplest authentication scenario, where a client just wants to authenticate the server and encrypt all data&quot; actually works and the encrypted bytes do flow over the wire from a grpc c++ client to its grpc c++ server and the said grpc c++ server decrypts these bytes and passes them onto the underlying application? Along with any other non code instructions if those are needed.</p>
  <p>Changing the code on the grpc c++ server side to use the <code>grpc::SslServerCredentials( grpc::SslServerCredentialsOptions() )</code> leads to a code that compiles, links, runs but quickly dumps core with the following error message:</p>
  <pre><code>E0816 19:24:26.270527688   15081 ssl_security_connector.cc:268] Handshaker factory creation failed with TSI_INVALID_ARGUMENT.
  E0816 19:24:26.270775700   15081 server_secure_chttp2.cc:124] {&quot;created&quot;:&quot;@1629141866.270756657&quot;,&quot;description&quot;:&quot;Unable to create secure server with credentials of type Ssl&quot;,&quot;file&quot;:&quot;/opt/grpc_source/src/core/ext/transport/chttp2/server/secure/server_secure_chttp2.cc&quot;,&quot;file_line&quot;:104}
  Segmentation fault
  </code></pre>
  <p>Running both the grpc c++ client and the grpc c++ server (on two different CentOS 7 boxes) in the &quot;clear text&quot; or &quot;non secure&quot; mode works perfectly fine - the said client happily packages its data into the protobuf message, executes the grpc call, the grpc c++ server receives the message and all is good.</p>
  <p>Does anyone have any idea about what has to be done on the grpc c++ server side, I suspect, so that the functionality advertised on the grpc documentation site actually works - I am not looking to mess about with the custom certificate files, if it can be helped at all.</p>
  <p>Using the default and built-in Ssl/Tls mechanism of the native grpc libraries is perfectly fine. In other words, some minimal viable grpc security is sufficient.</p>
  <p>Thank you for any constructive insight.</p>