確保 gRPC 的通信安全我們有很多種不同的方式，其中一種，就是對通信過程進行加密，使用上 TLS。對于 TLS 如何加密，如何協商密鑰，這些我這里就不再啰嗦了，我在之前的文章中都已經介紹過了。咱們就直接來看具體的玩法。
今天我們要在前文的基礎之上，來和小伙伴們聊一聊如何確保 gRPC 的通信安全。
確保 gRPC 的通信安全我們有很多種不同的方式，其中一種，就是對通信過程進行加密，使用上 TLS。對于 TLS 如何加密，如何協商密鑰，這些我這里就不再啰嗦了，我在之前的文章中都已經介紹過了。咱們就直接來看具體的玩法。
這塊整體上可以分為兩大類：
我們分別來看。
1. 啟用單向安全連接
單向安全連接其實就是說只需要客戶端校驗服務端，確保客戶端收到的消息來自預期的服務端，整個的校驗就涉及到我們前文所說的 TLS、CA 等內容了，具體流程是這樣：
- 首先我們先在自己電腦本地生成一個自簽名的 CA 證書。
- 利用這個 CA 證書，生成一個服務證書。
大致上就這兩個步驟就行了，然后在客戶端和服務端中分別加載相應的證書即可。
上面我們提到了需要先有一個自簽名的 CA 證書，這一步其實也可以省略，省略之后就直接生成一個自簽名的服務證書即可，然后在客戶端和服務端都使用這個服務證書。
來實際操作一下。
先自己安裝一下 openssl 工具，配置一下環境變量，軟件安裝比較簡單，我這里就不啰嗦了。
1.1 生成 CA 證書
首先我們來看下如何生成 CA 證書。
一共是三個步驟：
- 生成 .key 私鑰文件：
openssl genrsa -out ca.key 2048
- out 表示輸出的文件名。
- 2048 表示私鑰的位數。
- 生成 .csr 證書簽名請求文件：
CSR 即證書簽名申請（Certificate Signing Request），獲取 SSL 證書，需要先生成 CSR 文件并提交給證書頒發機構（CA）。CSR 包含了用于簽發證書的公鑰、用于辨識的名稱信息（Distinguished Name）（例如域名）、真實性和完整性保護（例如數字簽名），通常從 Web 服務器生成 CSR，同時創建加解密的公鑰私鑰對。
openssl req -new -key ca.key -out ca.csr -subj "/C=CN/L=GuangZhou/O=javaboy/CN=local.javaboy.org"
- subj 中描述的是一些國家、城市、組織以及通用名稱（域名）等信息。
- 自簽名生成 .crt 證書文件
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -subj "/C=CN/L=GuangZhou/O=javaboy/CN=local.javaboy.org"
- -x509 表示是要生成自簽名證書。
- -days 3650 表示證書有效期是 3650 天。
- -key 表示生成證書所需要的密鑰。
有人說公鑰呢？公鑰其實就在 .crt 證書文件中。
1.2 生成服務證書
再來看生成服務證書，生成服務證書和生成 CA 證書其實整個過程差不多，唯一的區別在于，CA 證書是自簽名的，而服務證書是 CA 的私鑰給簽名的，就這個差別。
- 生成 .key 私鑰文件：
openssl genrsa -out server.key 2048
- 生成 .csr 證書簽名請求文件：
openssl req -new -key server.key -out server.csr -subj "/C=CN/L=GuangZhou/O=javaboy/CN=local.javaboy.org"
- 簽名生成 .crt 證書文件
openssl x509 -req -days 3650 -in server.csr -out server.crt -CA ca.crt -CAkey ca.key
- -req 和 -in 指定了 server.csr，這個是證書請求文件，這里實際上是表示簽署證書請求文件。
證書現在就生成完畢。
這里我們生成的私鑰都是 .key? 文件，這個用我們 Java 代碼加載的時候會有問題，我們要將之轉為 .pem 格式然后再用 Java 代碼進行加載，轉換的命令如下：
openssl pkcs8 -topk8 -inform pem -in server.key -outform pem -nocrypt -out server.pem
1.3 單向加密
現在證書都有了，在當前項目目錄下新建一個文件夾，專門用來放證書，項目目錄結構如下：
├── certs
│ ├── ca.crt
│ ├── ca.csr
│ ├── ca.key
│ ├── server.crt
│ ├── server.csr
│ ├── server.key
│ └── server.pem
├── grpc_api
│ ├── pom.xml
│ ├── src
│ └── target
├── grpc_client
│ ├── pom.xml
│ ├── src
│ └── target
├── grpc_server
│ ├── pom.xml
│ ├── src
│ └── target
└── pom.xml
我們看下代碼該如何改造實現單向加密通信。
先來看服務端代碼：
public void start() throws IOException {
int port = 50051;
File certFile = Paths.get( "certs", "server.crt").toFile();
File keyFile = Paths.get("certs", "server.pem").toFile();
server = ServerBuilder.forPort(port)
.addService(new LoginServiceImpl())
.addService(ServerInterceptors.intercept(new HelloServiceImpl(), new AuthInterceptor()))
.useTransportSecurity(certFile,keyFile)
.build()
.start();
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
LoginServer.this.stop();
}));
}大家注意，由于我生成簽名的時候，使用的域名是 local.javaboy.org? 這是我在本地 hosts 文件中配置的，指向本地地址，所以在后續的通信中，我使用的域名都將是 local.javaboy.org。
- Paths.get 方法表示從項目的根目錄下開始查找文件，參數是可變長度參數，參數共同組成文件完整路徑。
- 服務端需要加載服務簽名和服務私鑰，簽名證書是客戶端驗證服務端身份用的，私鑰則是服務端解密客戶端消息使用的。
服務端的改造就這些。
再來看客戶端的改造：
File certFile = Paths.get( "certs", "ca.crt").toFile();
SslContext sslContext = GrpcSslContexts.forClient().trustManager(certFile).build();
ManagedChannel channel = NettyChannelBuilder.forAddress("local.javaboy.org", 50051)
.useTransportSecurity()
.sslContext(sslContext)
.build();
客戶端主要是加載 CA 證書文件，服務端的證書就是 CA 私鑰簽發的，但是需要 CA 公鑰也就是 ca.crt 進行驗簽，所以這里客戶端加載了 ca.crt 即可。
好啦，整體上的流程差不多就是這個樣子。
2. 啟用 mTLS 安全連接
上面的例子只是客戶端校驗了服務端的身份，服務端并沒有校驗客戶端的身份，如果想要雙向校驗，那么就把上面的流程對稱操作一遍就可以了。
首先我們需要為客戶端生成相應的證書，步驟跟前面也基本上一直，使用 CA 進行簽名，如下：
- 生成 .key 私鑰文件：
openssl genrsa -out client.key 2048
- 生成 .csr 證書簽名請求文件：
openssl req -new -key client.key -out client.csr -subj "/C=CN/L=GuangZhou/O=javaboy/CN=local.javaboy.org"
- 簽名生成 .crt 證書文件
openssl x509 -req -days 3650 -in client.csr -out client.crt -CA ca.crt -CAkey ca.key
然后來看看代碼。
先來看服務端：
public void start() throws IOException {
int port = 50051;
File certFile = Paths.get( "certs", "server.crt").toFile();
File keyFile = Paths.get("certs", "server.pem").toFile();
File caFile = Paths.get("certs", "ca.crt").toFile();
server = NettyServerBuilder.forPort(port)
.addService(new LoginServiceImpl())
.addService(ServerInterceptors.intercept(new HelloServiceImpl(), new AuthInterceptor()))
.sslContext(GrpcSslContexts.forServer(certFile,keyFile).trustManager(caFile).clientAuth(ClientAuth.REQUIRE).build())
.build()
.start();
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
LoginServer3.this.stop();
}));
}服務端要加載的文件多了 ca.crt，這是給客戶端驗簽的時候需要用到。
再來看看客戶端代碼：
File caFile = Paths.get( "certs", "ca.crt").toFile();
File certFile = Paths.get( "certs", "client.crt").toFile();
File keyFile = Paths.get( "certs", "client.pem").toFile();
SslContext sslContext = GrpcSslContexts.forClient().trustManager(caFile)
.keyManager(certFile, keyFile).build();
ManagedChannel channel = NettyChannelBuilder.forAddress("local.javaboy.org", 50051)
.useTransportSecurity()
.sslContext(sslContext)
.build();
客戶端多了 client.crt? 和 client.pem，兩者的作用根服務端中這兩者的作用基本一致，前文已有說明，這里就不再贅述了。
好啦，如此之后，我們的 gRPC 通信就加上了 TLS 的外殼，更加安全了。
