docker - goproxy 背后的 gPRC 返回证书错误，在没有代理的情况下工作正常

Question

我有一个 gRPC 客户端和服务器，都使用 ssl 证书进行保护。如果中间没有代理，这些工作很好。作为测试，当我故意创建有缺陷的证书时，它失败了。稍后将在本文中证明这不是证书问题。

gRPC 服务器代码:

// Creates a new gRPC server
// Create the TLS credentials
creds, err := credentials.NewServerTLSFromFile("configs/cert/servercert.pem", "configs/cert/serverkey.pem")
if err != nil {
    log.Fatalf("could not load TLS keys: %s", err)
}
// Create an array of gRPC options with the credentials
opts := []grpc.ServerOption{grpc.Creds(creds)}
// create a gRPC server object
s := grpc.NewServer(opts...)

gRPC 客户端代码:

// Create the client TLS credentials
creds, err := credentials.NewClientTLSFromFile("configs/cert/servercert.pem", "")
if err != nil {
    log.Fatalf("could not load tls cert: %s", err)
}

conn, err := grpc.Dial(grpcUri, grpc.WithTransportCredentials(creds))
if err != nil {
    log.Fatalf("Unable to connect: %v", err)
}

现在我正在尝试使用转发代理(我已经测试过并且在正常的 HTTP api 请求上工​​作正常)。然而，它在通过代理的 gRPC 请求上总是失败。

我正在使用 cuttle内部使用 goproxy使用以下设置。请注意，InsecureSkipVerify bool 值已尝试 true 和 false。根据我对 SSL 的(有限)理解，这需要为 false，因为它将在线检查证书，并且这些证书是自签名的，因此自然会失败。但是，我再次尝试了 true 和 false

// Config proxy.
proxy := goproxy.NewProxyHttpServer()
proxy.Tr = &http.Transport{
    // Config TLS cert verification.
    TLSClientConfig: &tls.Config{InsecureSkipVerify: !cfg.TLSVerify},
    Proxy:           http.ProxyFromEnvironment,
}

在 gRPC 客户端和服务器之间运行代理会导致以下错误:

transport: authentication handshake failed: x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate "test server"

这表明这是一个证书问题，但是，如前所述和测试，gRPC 在没有代理的情况下也能完美运行。

另请注意:我不想在代理后面运行 gRPC，但由于开发环境而被迫这样做。 gRPC 服务器和代理在同一台 docker 机器上运行。具有相同的 IP 地址会导致以下配置，这只会相互抵消(相信我，我无论如何都试过了)。

ENV http_proxy 192.168.99.100:3128
ENV https_proxy 192.168.99.100:3128
ENV no_proxy 192.168.99.100 # <- this would be the gRPC server IP, which is the same as the proxy. resulting in nothing being run through a proxy.

拆分在 docker 中寻址的 ip 可以解决这个问题，但是，我什么也学不到，也想解决这个问题。我试过像回答 here 这样的配置然而，要设置不同的 Docker 内部 IP，IP 将保持为空(仅设置网络)并且访问新 IP 将超时。

Answer 1

背景:

TLS 连接的每一端都需要预先安排的信任。大多数客户端在连接到远程主机时使用系统信任链(GeoTrust、DigiCert CA 的受信任证书都列在那里并允许您安全地访问像 https://facebook.com、https://google.com 等网站)

go，在使用 TLS 时，在联系服务器时将默认使用系统信任链。在开发自定义解决方案时，很可能您的应用程序服务器的公共(public)证书不在此系统信任链中。所以你有两个选择:

• 通过 InsecureSkipVerify: true 禁用信任(DON'T 这样做!)
• 为您的客户添加自定义信任

您的应用程序服务器很可能有一个自签名证书，所以它是 easy获取此的公共(public)证书部分。您还可以使用 openssl 等工具查看服务器的公共(public)证书- 使用链接的解决方案，您不仅可以为自己的开发服务器获取公共(public)证书，还可以为任何其他远程服务获取公共(public)证书 - 只需提供主机名和端口即可。

---

所以只是总结一下你的情况。你有:

Client <- TLS -> Server

但是想要:

Client <-TLS-> Proxy <-TLS-> Server

因此您的客户端现在不再信任服务器，而是只需要信任代理 - 因为它只直接与代理对话。代理很可能有一个自签名证书(见上文关于如何提取信任证书)。完成后，更新您的 go 代码以使用此自定义信任文件，如下所示:

// Get the SystemCertPool, continue with an empty pool on error
rootCAs, err := x509.SystemCertPool() // <- probably not needed, if we're only ever talking to this single proxy
if err != nil || rootCAs == nil {
    rootCAs = x509.NewCertPool()
}

// Read in the custom trust file
certs, err := ioutil.ReadFile(localTrustFile)
if err != nil {
    log.Fatalf("Failed to append %q to RootCAs: %v", localTrustFile, err)
}

// Append our cert to the system pool
if ok := rootCAs.AppendCertsFromPEM(certs); !ok {
    log.Fatalf("failed to append custom cert")
}

tlsConfig := &tls.Config{
    RootCAs: rootCAs,
}

代理也需要信任服务器 - 所以如果服务器的证书不在系统信任链中，那么它需要像上面类似的 tls.Config 设置。