Haproxy 授权来自 AWS API 网关的流量
Haproxy to authorize traffic from AWS API Gateway
我已经使用 AWS API 网关设置了一个基本 API，我想 link 我的端点到我在 EC2 实例上 运行 的服务（使用 "HTTP Proxy" 集成类型）。我读过，为了锁定我的 EC2 服务器仅接受来自 API 网关的流量，我基本上有两个选项之一：
- 将 EC2 实例放在 VPC 后面，并使用具有 VPC 权限的 Lambda 函数（而不是 HTTP 代理）作为 "pass through" 请求 API
- 在 API 网关中创建一个客户端证书，使用该证书发出我的后端请求，并在 EC2 实例上验证该证书。
我想使用#2 的变体，而不是在 EC2 服务实例本身上验证证书，我想在另一个实例 运行 Haproxy 上进行验证。我已经使用 Haproxy 设置了第二个 EC2 实例，并将其指向我的另一个实例作为后端。我已经锁定了我的服务实例，所以它只会接受来自 Haproxy 实例的请求。这一切都在起作用。我一直在努力弄清楚如何在 Haproxy 机器上验证 AWS 网关客户端证书（我已经生成）。我已经进行了大量的谷歌搜索，令人惊讶的是，关于如何做这件事的信息为零。几个问题：
- 我读过的所有内容似乎都表明我需要在我的 Haproxy 机器上生成 SSL 服务器证书并在配置中使用它们。我是否必须这样做，或者我是否可以在不生成任何其他证书的情况下验证 AWS 客户端证书？
- 我阅读的内容表明我需要生成一个 CA，然后使用该 CA 生成服务器和客户端证书。如果我确实需要生成服务器证书（在 Haproxy 机器上），如果我无权访问亚马逊用来创建网关客户端证书的 CA，我该如何生成它们？据我所知，我只能访问客户端证书本身。
这里有什么帮助吗？
解决方案更新
- 首先，我必须将我的 HAproxy 版本升级到 v1.5.14，这样我才能获得 SSL 功能
- 我最初尝试使用 letsencrypt 生成官方证书。虽然我能够让 API 网关使用此证书，但我无法在 API 网关可以接受的 HAproxy 机器上生成 letsencrypt 证书。该问题表现为来自 API 网关的 "Internal server error" 响应以及详细 CloudWatch 日志中的 "General SSLEngine problem"。
- 然后我从 Gandi 购买了一个通配符证书，并在 HAproxy 机器上尝试了这个，但最初 运行 遇到了完全相同的问题。但是，我能够确定我的 SSL 证书的结构不是 API 网关想要的。我用谷歌搜索并在这里找到了 Gandi 链：
https://www.gandi.net/static/CAs/GandiStandardSSLCA2.pem
然后我将我的 SSL 文件结构化如下：
-----BEGIN PRIVATE KEY-----
# private key I generated locally...
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
# cert from gandi...
-----END CERTIFICATE-----
# two certs from file in the above link
我保存了这个新的 PEM 文件（haproxy.pem）并在我的 HAproxy 前端绑定语句中使用它，如下所示：
bind :443 ssl crt haproxy.pem verify required ca-file api-gw-cert.pem
上述绑定语句中的 api-gw-cert.pem 是一个包含我在 API 网关控制台中生成的客户端证书的文件。现在，HAproxy 机器可以正确阻止来自网关以外任何地方的任何流量。
我认为您混淆了服务器证书和客户端证书。在本例中 API Gateway 是客户端，HAProxy 是服务器。您希望 HAProxy 验证 API 网关发送的客户端证书。 API 网关将为您生成证书，您只需配置 HAProxy 以验证它处理的每个请求中是否存在证书。
我猜您可能正在查看 this tutorial 他们告诉您生成客户端证书的位置，然后配置 HAProxy 以验证该证书。该教程的 "generate the cert" 部分可以跳过，因为 API Gateway 正在为您生成证书。
您只需单击 API 网关中的 "Generate" 按钮，然后 copy/paste 它向您提供的证书内容并将其保存为 HAProxy 上的 .pem 文件服务器。现在我不是 HAProxy 的大用户，但我认为以该教程中的示例为例，你的 HAProxy 配置应该类似于：
bind 192.168.10.1:443 ssl crt ./server.pem verify required
The reading I have done suggests I would need to generate a CA and then use that CA to generate both the server and client certs.
这是一种方法，但不适用于这种情况。
您的 HAProxy 需要使用受信任的 CA 签名的有效 SSL 证书进行配置——不是签署客户端证书的证书，也不是您创建的证书。它需要是由 public 受信任的 CA 签署的证书，其根证书位于 API 网关的后端系统的信任库中... 应该 与您的网络浏览器信任的基本相同，但可能是一个子集。
正如您的 Web 浏览器不会在不抛出您必须绕过的警告的情况下将 SSL 发送给带有自签名证书的服务器一样，API 网关的后端也不会与不受信任的证书（并且没有绕过）。
我只想说，您需要让 API 网关通过 TLS 与您的 HAProxy 对话，然后再 尝试让它使用客户端证书，否则您引入了太多未知数。另请注意，您不能为此使用 Amazon Certificate Manager 证书，因为这些证书仅适用于 CloudFront 和 ELB，它们都不直接支持客户端证书。
一旦 HAProxy 与 API 网关一起工作，您就需要对其进行配置以对客户端进行身份验证。
您的 bind 声明中需要 ssl 和 verify required，但是您无法验证 SSL 客户端证书而不需要验证它 against.
I only have access to the client cert itself, from what I can tell.
这就是您所需要的。
bind ... ssl ... verify required ca-file /etc/haproxy/api-gw-cert.pem.
SSL 证书本质上是一个信任层次结构。树顶部的信任是明确的。通常，CA 是显式信任的，它签署的任何内容都是隐式信任的。 CA "vouches for" 它签署的证书...并且对于它使用 CA 属性集签署的证书，它也可以在它们下签署证书，扩展隐式信任。
不过，在这种情况下，您只需将客户端证书作为 CA 文件放入，然后是客户端证书 "vouches for"... 本身。提供相同证书的客户端是可信的，其他任何人都断开连接。当然，只有证书不足以让客户端与您的代理对话——客户端还需要 API Gateway 拥有的匹配私钥。
因此，请考虑这两个单独的要求。首先获取 API 网关通过 TLS 与您的代理通信...然后，根据客户端证书进行身份验证实际上是更容易的部分。
我已经使用 AWS API 网关设置了一个基本 API，我想 link 我的端点到我在 EC2 实例上 运行 的服务（使用 "HTTP Proxy" 集成类型）。我读过，为了锁定我的 EC2 服务器仅接受来自 API 网关的流量，我基本上有两个选项之一：
- 将 EC2 实例放在 VPC 后面，并使用具有 VPC 权限的 Lambda 函数（而不是 HTTP 代理）作为 "pass through" 请求 API
- 在 API 网关中创建一个客户端证书，使用该证书发出我的后端请求，并在 EC2 实例上验证该证书。
我想使用#2 的变体，而不是在 EC2 服务实例本身上验证证书，我想在另一个实例 运行 Haproxy 上进行验证。我已经使用 Haproxy 设置了第二个 EC2 实例，并将其指向我的另一个实例作为后端。我已经锁定了我的服务实例，所以它只会接受来自 Haproxy 实例的请求。这一切都在起作用。我一直在努力弄清楚如何在 Haproxy 机器上验证 AWS 网关客户端证书（我已经生成）。我已经进行了大量的谷歌搜索，令人惊讶的是，关于如何做这件事的信息为零。几个问题：
- 我读过的所有内容似乎都表明我需要在我的 Haproxy 机器上生成 SSL 服务器证书并在配置中使用它们。我是否必须这样做，或者我是否可以在不生成任何其他证书的情况下验证 AWS 客户端证书？
- 我阅读的内容表明我需要生成一个 CA，然后使用该 CA 生成服务器和客户端证书。如果我确实需要生成服务器证书（在 Haproxy 机器上），如果我无权访问亚马逊用来创建网关客户端证书的 CA，我该如何生成它们？据我所知，我只能访问客户端证书本身。
这里有什么帮助吗？
解决方案更新
- 首先，我必须将我的 HAproxy 版本升级到 v1.5.14，这样我才能获得 SSL 功能
- 我最初尝试使用 letsencrypt 生成官方证书。虽然我能够让 API 网关使用此证书，但我无法在 API 网关可以接受的 HAproxy 机器上生成 letsencrypt 证书。该问题表现为来自 API 网关的 "Internal server error" 响应以及详细 CloudWatch 日志中的 "General SSLEngine problem"。
- 然后我从 Gandi 购买了一个通配符证书，并在 HAproxy 机器上尝试了这个，但最初 运行 遇到了完全相同的问题。但是，我能够确定我的 SSL 证书的结构不是 API 网关想要的。我用谷歌搜索并在这里找到了 Gandi 链： https://www.gandi.net/static/CAs/GandiStandardSSLCA2.pem 然后我将我的 SSL 文件结构化如下：
-----BEGIN PRIVATE KEY----- # private key I generated locally... -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- # cert from gandi... -----END CERTIFICATE----- # two certs from file in the above link
我保存了这个新的 PEM 文件（haproxy.pem）并在我的 HAproxy 前端绑定语句中使用它，如下所示：
bind :443 ssl crt haproxy.pem verify required ca-file api-gw-cert.pem
上述绑定语句中的 api-gw-cert.pem 是一个包含我在 API 网关控制台中生成的客户端证书的文件。现在，HAproxy 机器可以正确阻止来自网关以外任何地方的任何流量。
我认为您混淆了服务器证书和客户端证书。在本例中 API Gateway 是客户端，HAProxy 是服务器。您希望 HAProxy 验证 API 网关发送的客户端证书。 API 网关将为您生成证书，您只需配置 HAProxy 以验证它处理的每个请求中是否存在证书。
我猜您可能正在查看 this tutorial 他们告诉您生成客户端证书的位置，然后配置 HAProxy 以验证该证书。该教程的 "generate the cert" 部分可以跳过，因为 API Gateway 正在为您生成证书。
您只需单击 API 网关中的 "Generate" 按钮，然后 copy/paste 它向您提供的证书内容并将其保存为 HAProxy 上的 .pem 文件服务器。现在我不是 HAProxy 的大用户，但我认为以该教程中的示例为例，你的 HAProxy 配置应该类似于：
bind 192.168.10.1:443 ssl crt ./server.pem verify required
The reading I have done suggests I would need to generate a CA and then use that CA to generate both the server and client certs.
这是一种方法，但不适用于这种情况。
您的 HAProxy 需要使用受信任的 CA 签名的有效 SSL 证书进行配置——不是签署客户端证书的证书，也不是您创建的证书。它需要是由 public 受信任的 CA 签署的证书，其根证书位于 API 网关的后端系统的信任库中... 应该 与您的网络浏览器信任的基本相同，但可能是一个子集。
正如您的 Web 浏览器不会在不抛出您必须绕过的警告的情况下将 SSL 发送给带有自签名证书的服务器一样，API 网关的后端也不会与不受信任的证书（并且没有绕过）。
我只想说，您需要让 API 网关通过 TLS 与您的 HAProxy 对话，然后再 尝试让它使用客户端证书，否则您引入了太多未知数。另请注意，您不能为此使用 Amazon Certificate Manager 证书，因为这些证书仅适用于 CloudFront 和 ELB，它们都不直接支持客户端证书。
一旦 HAProxy 与 API 网关一起工作，您就需要对其进行配置以对客户端进行身份验证。
您的 bind 声明中需要 ssl 和 verify required，但是您无法验证 SSL 客户端证书而不需要验证它 against.
I only have access to the client cert itself, from what I can tell.
这就是您所需要的。
bind ... ssl ... verify required ca-file /etc/haproxy/api-gw-cert.pem.
SSL 证书本质上是一个信任层次结构。树顶部的信任是明确的。通常，CA 是显式信任的，它签署的任何内容都是隐式信任的。 CA "vouches for" 它签署的证书...并且对于它使用 CA 属性集签署的证书，它也可以在它们下签署证书，扩展隐式信任。
不过，在这种情况下，您只需将客户端证书作为 CA 文件放入，然后是客户端证书 "vouches for"... 本身。提供相同证书的客户端是可信的，其他任何人都断开连接。当然，只有证书不足以让客户端与您的代理对话——客户端还需要 API Gateway 拥有的匹配私钥。
因此，请考虑这两个单独的要求。首先获取 API 网关通过 TLS 与您的代理通信...然后，根据客户端证书进行身份验证实际上是更容易的部分。