Adding certificate information to a server implementation is twofold: implement logic to load credentials and create a TransportCredentials(http://mng.bz/gBAe) instance; then use this function within the interceptor to handle credentials verification out of the box for each request.
This means the following steps are applied (figure 6.8):
1 The client sends a gRPC call to the server.
2 The server represents its shared certificate with its public key.
3 The client validates this certificate on a CA. For now, the CA cert contains client and server shared certificates.
4 After client validation, the client presents its shared certificate with its public key to the server.
5 The server validates the shared certificate on the CA.
6 After successful verification, the client receives a response from the gRPC call.
If we wanted to implement this flow on the client and server side, we could use already generated shared certificates for both the server and client side. Since the CA signs the certificate, those shared certificates ( client.crt, server.crt) are already in ca.crt. For development purposes, we will generate a cert pool in the server and client and append client and server certificates there. Finally, we will put TLS configuration inside gRPC server options.
This implementation is useful for local development, but in a production environment, it is best practice to delegate certificate management to a third party.
