It appears that omitting it causes grpc to use the hosts' default cert data.
This was brought up (as I had implemented this method incorrectly) in:
https://github.com/mixer/etcd3/issues/28#issuecomment-319510441

Auto_set_flakes also reruns tests that timeout

Pre-populate xdg-cache-home to deflake python kokoro build

Updating roots from Mozilla.

Fix implicit fallthrough warning on GCC 7.x

Flow Control

Fix a racey test in ruby

Node: replace custom deprecation warning with existing solution

Actually test grpc++_unsecure

Add a GrpcLibraryInitializer to client_context.cc

Initialize initiating_exec_ctx_or_null

Fix leak if duplicated static metadata

Convenient Fuzz Tracing

Add comment and test for API of a parameter to grpc_call_cancel_with_status

Get more useful debug info out of Jenkins

Fix two memory leak points in ObjC

Clean up grpc++_unsecure so that it doesn't require secure content anymore

Prevent race in trying to compile grpc.pb.cc file before pb.h exists

It's feasible that a program be written/linked such that it only use
ClientContext from grpc++, which could end up with the other instances
of GrpcLibraryInitializer not ending up in the final binary.  Add a
GrpcLibraryInitializer to client_context.cc to ensure that the library
is initialized.  The primary side-effect of the library not being
initialized when only using a ClientContext is that the destructor for
ClientContext indirectly ends up trying to call through
g_core_codegen_interface when destructing its metadata, which is null.

Connect auth doc

Fix 'Release of a suspended object' issue in GRXBufferedPipe