gRPC C++ SSL 认证实战：基于 SslServerCredentials 与 SslCredentials 搭建 TLS 加密 RPC 服务

gRPC C SSL 认证实战基于 SslServerCredentials 与 SslCredentials 搭建 TLS 加密 RPC 服务【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo导读本文以 gRPC 官方 C 示例中的 Authentication Example位于本仓库 src/third_party/grpc/dist/examples/cpp/auth/为蓝本完整讲解如何为 gRPC 服务端与客户端启用基于 SSL/TLS 的双向安全信道服务端通过grpc::SslServerCredentials提供加密监听端口客户端通过grpc::SslCredentials建立受信任的加密连接。读完本文你将掌握 gRPC C 中 SSL 凭据的加载方式、证书信任链的组织方法以及如何使用 Bazel 构建并运行一个端到端的 TLS 认证 gRPC 示例并能将同样的模式迁移到自己的 RPC 服务中。Overview为什么需要 SSL 认证SSLSecure Sockets Layer是一种广泛使用的加密协议用于提供端到端的通信安全。在 gRPC 中RPC 调用默认通过 HTTP/2 传输虽然性能优秀但明文信道上的数据与身份都可以被中间人窃听或篡改。为了对 RPC 流量进行加密并验证通信双方身份gRPC C 提供了两种核心凭据类型grpc::SslServerCredentials服务端使用绑定到监听端口对所有接入的连接启用 TLS 握手与证书校验grpc::SslCredentials客户端使用绑定到 Channel向服务端发起 TLS 握手。本示例使用预先创建好的公钥/私钥对来完成服务器端认证Server Authentication三份凭据文件分别为文件作用localhost.crt服务器证书含公钥代表服务器的身份localhost.key服务器私钥仅服务端持有root.crt证书颁发机构CA证书用于校验服务器证书的可信性三份文件都随示例存放在 src/third_party/grpc/dist/examples/cpp/auth/credentials/ 目录下。其中 root.crt 是自签 CA 证书在真实生产环境中应替换为受信任 CA 签发的证书链。端到端运行构建并启动 TLS 加密的 HelloWorld 服务构建前提示例假设你已有一套可用的 gRPC C 构建环境构建方式二选一Bazel或CMake。无论采用哪种方式都要在本目录examples/cpp/auth下执行构建命令以确保程序能以相对路径正确读取凭据文件——这一点对示例能否运行至关重要因为代码中加载证书走的就是相对路径详见下文源码解析。本仓库随示例提供了完整的 Bazel 构建文件 src/third_party/grpc/dist/examples/cpp/auth/BUILD它声明了两个二进制目标ssl_client依赖 ssl_client.cc并将credentials/root.crt作为运行期数据文件data打入ssl_server依赖 ssl_server.cc并将credentials/localhost.crt与credentials/localhost.key作为运行期数据文件打入。两个目标都通过defines [BAZEL_BUILD]开启 Bazel 构建宏从而使源码切换到仓库根目录相对路径examples/cpp/auth/credentials/...若走 CMake 构建则使用当前目录相对路径credentials/...。这一点在源码中通过#ifdef BAZEL_BUILD分支显式区分后面会详细展开。启动服务端在examples/cpp/auth目录下构建完成后启动服务端它将监听50051端口$ ./ssl_server服务端启动后会打印监听地址源码中通过absl::StrFormat(0.0.0.0:%d, port)构造绑定地址默认端口 50051随后进入server-Wait()阻塞等待直到有线程负责触发关闭。启动客户端另开一个终端运行客户端$ ./ssl_client如果一切顺利客户端会输出Greeter received: Hello world这表示客户端已通过 TLS 信道向服务端成功发起SayHelloRPC客户端发送名字world服务端返回Hello world整个过程在 SSL 加密连接上完成。服务端源码剖析用 SslServerCredentials 绑定加密监听端口服务端核心逻辑位于 ssl_server.cc其关键步骤如下第一步加载服务端证书与私钥。服务端通过LoadStringFromFile定义于 helper.cc其声明见 helper.h将 PEM 格式文件读取为字符串grpc::SslServerCredentialsOptions::PemKeyCertPair key_cert_pair { LoadStringFromFile(kServerKeyPath), LoadStringFromFile(kServerCertPath)};PemKeyCertPair内部是一个字符串对顺序为私钥在前、证书在后这是 gRPC 定义好的字段次序使用时不要颠倒。第二步组装SslServerCredentialsOptions。将密钥证书对压入pem_key_cert_pairs列表——该字段是向量类型意味着服务端可以一次性提供多对证书例如配置 SNI 或轮换证书本示例仅提供一对grpc::SslServerCredentialsOptions ssl_options; ssl_options.pem_key_cert_pairs.emplace_back(key_cert_pair);第三步以 SSL 凭据绑定监听地址。将grpc::SslServerCredentials(ssl_options)传给ServerBuilder::AddListeningPort该端口上的所有连接即强制走 TLSbuilder.AddListeningPort(server_address, grpc::SslServerCredentials(ssl_options)); builder.RegisterService(service); std::unique_ptrServer server(builder.BuildAndStart());服务实现采用 gRPC 的Callback APIGreeter::CallbackService与ServerUnaryReactorSayHello收到请求后拼接Hello name前缀写入响应随后通过context-DefaultReactor()-Finish(Status::OK)完成这次一元 RPC。证书路径的构建差异。源码中根据构建方式区分了两组路径常量#ifdef BAZEL_BUILD constexpr char kServerCertPath[] examples/cpp/auth/credentials/localhost.crt; constexpr char kServerKeyPath[] examples/cpp/auth/credentials/localhost.key; #else constexpr char kServerCertPath[] credentials/localhost.crt; constexpr char kServerKeyPath[] credentials/localhost.key; #endif这解释了 README 中必须在示例目录下运行的要求CMake 构建时相对路径基于当前工作目录解析若在仓库根目录运行会找不到证书并触发helper.cc中的abort()。客户端源码剖析用 SslCredentials 建立受信任的 TLS 信道客户端核心逻辑位于 ssl_client.cc同样分为三步第一步加载 CA 根证书。客户端读取root.crt作为信任锚grpc::SslCredentialsOptions ssl_options; ssl_options.pem_root_certs LoadStringFromFile(kRootCertificate);pem_root_certs是客户端校验服务端证书的根证书集合。本示例中root.crt正是签发localhost.crt的 CA因此服务端证书可被验证通过若 CA 不匹配TLS 握手将失败。第二步以 SSL 凭据创建 Channel。目标地址默认为localhost:50051端口同样由ABSL_FLAG(uint16_t, port, 50051, ...)定义可用--port覆盖GreeterClient greeter( grpc::CreateChannel(target_str, grpc::SslCredentials(ssl_options)));第三步发起 RPC 并等待结果。客户端用异步 stub发起SayHello通过mutex condition_variable同步等待回调完成stub_-async()-SayHello(context, request, reply, mu, cv, done, status { status std::move(s); std::lock_guardstd::mutex lock(mu); done true; cv.notify_one(); });若status.ok()则返回服务端回复的消息否则打印错误码与错误信息并返回RPC failed——这为排查握手失败如证书校验不通过提供了直观的反馈入口。服务契约helloworld.proto 中的 Greeter 服务本示例的 RPC 契约定义在 src/third_party/grpc/dist/examples/protos/helloworld.proto属于 gRPC 入门经典的helloworld包syntax proto3; package helloworld; service Greeter { rpc SayHello (HelloRequest) returns (HelloReply) {} rpc SayHelloStreamReply (HelloRequest) returns (stream HelloReply) {} rpc SayHelloBidiStream (stream HelloRequest) returns (stream HelloReply) {} } message HelloRequest { string name 1; } message HelloReply { string message 1; }该 proto 除了演示用的一元 RPCSayHello还声明了服务端流式SayHelloStreamReply与双向流式SayHelloBidiStream。在 Bazel 构建中该 proto 经由//examples/protos:helloworld_cc_grpc目标生成 C 桩代码服务端与客户端源码中Greeter::CallbackService、Greeter::NewStub、Greeter::Stub等类型均来自这份生成代码。凭据文件说明与生产环境迁移建议示例随附的三份凭据文件都是为本地演示预生成的证书 CN 为localhost有效期延续至 2119 年仅用于示例。迁移到生产环境时请牢记以下几点私钥绝不外泄localhost.key必须严格保密只能存放在服务端任何形式的提交、分发都意味着凭据泄露替换为可信证书链用正式 CA或公司内部 PKI签发的证书替换localhost.crt/localhost.key并让客户端持有对应的root.crt或 CA 证书链证书与密钥格式gRPC 读取的是 PEM 格式字符串服务端的PemKeyCertPair次序固定为私钥证书客户端的pem_root_certs可包含多张 PEM 编码的 CA 证书双向认证扩展如需客户端也向服务端证明身份mTLS可在服务端SslServerCredentialsOptions中配置pem_root_certs并开启客户端证书校验客户端则在SslCredentialsOptions中补充自己的pem_private_key与pem_cert_chain——本示例是单向服务器认证这部分作为延伸方向供读者自行探索。小结gRPC C 的 SSL 认证模式非常清晰服务端把「证书私钥」封装进SslServerCredentialsOptions并通过SslServerCredentials绑定监听端口客户端把「CA 根证书」封装进SslCredentialsOptions并通过SslCredentials创建 Channel二者组合即形成一条端到端加密、服务器身份可验证的 RPC 信道。本示例的三步源码流程加载文件 → 组装 Options → 传入 Builder/CreateChannel可直接复用到任何 gRPC C 服务中运行示例时只需记住在examples/cpp/auth目录下构建、分终端启动ssl_server与ssl_client即可看到客户端输出Greeter received: Hello world。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考