Capture and return SSL errors to client

[AK]

For example, when SSL certificate expires or its verification fails gRPC call returns UNAVAILABLE (code 14). The actual error either goes to console or a log file, if it was set. However, that is not visible to clients. The user doesn't understand what went wrong from failed connection error. How to communicate more information about the errors back to client? I am using C++ server and client programs.

[Nathan Prat]

This thing is that ssl certificate erros will happen before the RPC reaches your code(ie the code for your routes), so you can't "send back" any high level error.
You have to handle those in your client.

[below is not a good idea]
You could also disable the server ssl verification(eg GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY), and then do whatever you want in you custom

AuthMetadataProcessor.

[Benjamin Krämer]

Just had the same problem at a customer site and costed me an hour to find out that I used the wrong certificate files. Had to enable logging and check the errors in there to see the SSL_VERIFY_FAILED. The channel itself only went to TransientFailure. Using C#, so not much look their either.

[AK]

I was in exact same situation. In my opinion, client should be notified of what caused the server to throw an error.

[connec...@gmail.com]

is there a way to return ssl error to client, i am getting UNAVAILABLE(code 14) when client certificate validation fails in server.

[Mark D. Roth]

UNAVAILABLE is the right status code in this situation, but the error message returned along with that status code should provide more useful information.  Fixing this will require some deep plumbing changes, so I don't know if it will happen anytime soon, but I have filed the following bug to track it:

https://github.com/grpc/grpc/issues/22885

[Sathish Kumar]

Hi Mark,

    Currently i am using grpc with secure channel (tls 1.3). if severe fails to validate client certificate(client's certificate: x509: certificate signed by unknown authority), client is getting grpc error code 2 with description "stream removed".

    Here "stream removed" doesn't give enough information about what happened in the server side. is there a way to propagate ssl error description back to grpc status till you fix this?