# gRPC C++ and Self Signed Certificates

https://jaredrhodes.com/blog/grpc-c-and-self-signed-certificates/

Playing around with gRPC with a C++ server caused an issue that took longer to solve than it should. Once the linker and other issues were solved, the following error started to follow:

7562 ssl\_transport\_security.cc:1238] Handshake failed with fatal error SSL\_ERROR\_SSL: error:100000c0:SSL routines:OPENSSL\_internal:PEER\_DID\_NOT\_RETURN\_A\_CERTIFICATE.

After searching, it lead me to [this file](https://github.com/grpc/grpc/blob/614331a50682c74fa8c02dcea674ca2ef5746225/include/grpc/grpc_security_constants.h#L60-L100) where the different enumeration values for the SSL handling could be set.

```c
/** Server does not request client certificate. A client can present a self
signed or signed certificates if it wishes to do so and they would be
accepted. */
GRPC_SSL_DONT_REQUEST_CLIENT_CERTIFICATE,
/** Server requests client certificate but does not enforce that the client
presents a certificate.

If the client presents a certificate, the client authentication is left to
the application based on the metadata like certificate etc.

The key cert pair should still be valid for the SSL connection to be
established. */
GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY,
/** Server requests client certificate but does not enforce that the client
presents a certificate.

If the client presents a certificate, the client authentication is done by
grpc framework (The client needs to either present a signed cert or skip no
certificate for a successful connection).

The key cert pair should still be valid for the SSL connection to be
established. */
GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_AND_VERIFY,
/** Server requests client certificate but enforces that the client presents a
certificate.

If the client presents a certificate, the client authentication is left to
the application based on the metadata like certificate etc.

The key cert pair should still be valid for the SSL connection to be
established. */
GRPC_SSL_REQUEST_AND_REQUIRE_CLIENT_CERTIFICATE_BUT_DONT_VERIFY,
/** Server requests client certificate but enforces that the client presents a
certificate.

The cerificate presented by the client is verified by grpc framework (The
client needs to present signed certs for a successful connection).

The key cert pair should still be valid for the SSL connection to be
established. */
GRPC_SSL_REQUEST_AND_REQUIRE_CLIENT_CERTIFICATE_AND_VERIFY
```

That lead me to find a more thorough breakdown of the use cases for each enumeration [in this GitHub issue reply](https://github.com/grpc/grpc/issues/15588#issuecomment-413595416). Summarizing the parts that mattered for my case:

- `GRPC_SSL_DONT_REQUEST_CLIENT_CERTIFICATE`: the server never asks; the client may present anything or nothing.
- `GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY`: the server requests a certificate but leaves signature enforcement to the application, which can verify self-signed certs through an out-of-band mechanism such as a registered hash.
- Request/require/verify are three independent axes: whether the server asks, whether the client must present, and whether the server verifies the presented cert against its SSL roots.
- None of it helps if the key pair itself is mismatched - the connection fails regardless.
- `grpc_auth_context` exposes peer properties (CN, PEM cert, SAN) you can inspect yourself.

**Finally, that lead me to understand that for self-signed certificates in development GRPC\_SSL\_REQUEST\_CLIENT\_CERTIFICATE\_BUT\_DONT\_VERIFY was the right enumeration.**