|
1 | 1 | # Encryption
|
2 | 2 |
|
3 |
| -The example for encryption includes two individual examples for TLS and ALTS |
4 |
| -encryption mechanism respectively. |
| 3 | +The example for encryption includes three individual examples for TLS, ALTS |
| 4 | +and mTLS encryption mechanism respectively. |
5 | 5 |
|
6 | 6 | ## Try it
|
7 | 7 |
|
@@ -35,7 +35,7 @@ In our example, we use the public/private keys created ahead:
|
35 | 35 | * "ca_cert.pem" contains the certificate (certificate authority)
|
36 | 36 | that can verify the server's certificate.
|
37 | 37 |
|
38 |
| -On server side, we provide the paths to "server.pem" and "server.key" to |
| 38 | +On server side, we provide the paths to "server_cert.pem" and "server_key.pem" to |
39 | 39 | configure TLS and create the server credential using
|
40 | 40 | [`credentials.NewServerTLSFromFile`](https://godoc.org/google.golang.org/grpc/credentials#NewServerTLSFromFile).
|
41 | 41 |
|
@@ -91,16 +91,29 @@ successfully up.
|
91 | 91 | In mutual TLS (mTLS), the client and the server authenticate each other. gRPC
|
92 | 92 | allows users to configure mutual TLS at the connection level.
|
93 | 93 |
|
| 94 | +In this example, we use the following public/private keys created ahead of time: |
| 95 | + |
| 96 | +* "server_cert.pem" contains the server's certificate (public key). |
| 97 | +* "server_key.pem" contains the server's private key. |
| 98 | +* "ca_cert.pem" contains the certificate of the certificate authority that can |
| 99 | + verify the server's certificate. |
| 100 | +* "client_cert.pem" contains the client's certificate (public key). |
| 101 | +* "client_key.pem" contains the client's private key. |
| 102 | +* "client_ca_cert.pem" contains the certificate of the certificate authority |
| 103 | + that can verify the client's certificate. |
| 104 | + |
94 | 105 | In normal TLS, the server is only concerned with presenting the server
|
95 | 106 | certificate for clients to verify. In mutual TLS, the server also loads in a
|
96 |
| -list of trusted CA files for verifying client presented certificates with. |
97 |
| -This is done via setting |
| 107 | +list of trusted CA files for verifying the client's presented certificates. |
| 108 | +This is done by setting |
98 | 109 | [`tls.Config.ClientCAs`](https://pkg.go.dev/crypto/tls#Config.ClientCAs)
|
99 | 110 | to the list of trusted CA files,
|
100 |
| -and setting [`tls.config.ClientAuth`](https://pkg.go.dev/crypto/tls#Config.ClientAuth) |
101 |
| -to [`tls.RequireAndVerifyClientCert`](https://pkg.go.dev/crypto/tls#RequireAndVerifyClientCert). |
| 111 | +and setting |
| 112 | +[`tls.config.ClientAuth`](https://pkg.go.dev/crypto/tls#Config.ClientAuth) |
| 113 | +to |
| 114 | +[`tls.RequireAndVerifyClientCert`](https://pkg.go.dev/crypto/tls#RequireAndVerifyClientCert). |
102 | 115 |
|
103 | 116 | In normal TLS, the client is only concerned with authenticating the server by
|
104 | 117 | using one or more trusted CA file. In mutual TLS, the client also presents its
|
105 |
| -client certificate to the server for authentication. This is done via setting |
| 118 | +client certificate to the server for authentication. This is done by setting |
106 | 119 | [`tls.Config.Certificates`](https://pkg.go.dev/crypto/tls#Config.Certificates).
|
0 commit comments