If the connections fail because of TLS issues, the RPCs will also fail, and the RPC errors will have the TLS error message.
The PR https://github.com/grpc/grpc-go/pull/2055/ <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgrpc%2Fgrpc-go%2Fpull%2F2055%2F&sa=D&sntz=1&usg=AFQjCNElfr4RLPulZ9BrEx2qcqDf_9Id2A> was to get the underlying connection error after dialing, without making an RPC. But we didn't get to finish the API design. On Monday, June 17, 2019 at 1:28:30 PM UTC-7, Dave Quigley wrote: > > The problem though is that is a configuration error. That is something > that a user of the software would need to have an idea of what is going on > to fix it and asking them to set the two environment variable and crawl > through internal grpc debug messages. Also that won't catch if your > certificates were not generated properly either. For example if you don't > have the caRoot cert installed on your machine but your saying the > certificates have to be verified. There was a pull request > https://github.com/grpc/grpc-go/pull/2055/ that would introduce the > ability to obtain the underlying network failure during a transient failure > but it seems to be closed and has gone nowhere. It would really be useful > for a person using grpc to develop a program to obtain this information so > it can let the user know that they have a configuration issue. > > On Monday, June 17, 2019 at 1:04:06 PM UTC-6, Eric Anderson wrote: >> >> Correct. If the client expects TLS you will get an error if connecting to >> a plaintext server. Some languages may provide more error information than >> others, but in all language that information is intended for developers, >> not programs to inspect. >> >> On Thu, Jun 13, 2019 at 12:00 PM Dave Quigley <[email protected]> wrote: >> >>> Hello, >>> >>> I have enabled TLS between a gRPC client and server and require client >>> auth to be done as part of the exchange. I also have a flag to say that the >>> server should be started without TLS securing the channel. However there >>> does not seem to be a good way to figure out when connecting from a client >>> that expects a TLS handshake that the reason it was unable to connect is >>> that there is a mismatch of expectations. Am I missing something here? It >>> seems that TLS handshake failures are just treated as transient failures >>> and there is no way to get more details. >>> >>> Dave >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "grpc.io" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/grpc-io/f4429762-f894-42df-99a1-f7bdd5301390%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/grpc-io/f4429762-f894-42df-99a1-f7bdd5301390%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/3c7f3db1-4662-4cc8-a971-de9d363959b8%40googlegroups.com.
