使用 Application Load Balancer TLS 中的相互身份验证 - Elastic Load Balancing
开始前的准备工作HTTP 标头宣传 CA 主题名称连接日志
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

使用 Application Load Balancer TLS 中的相互身份验证

相互TLS身份验证是传输层安全的一种变体 (TLS)。传统在服务器和客户端之间TLS建立安全的通信，服务器需要向其客户端提供其身份。使用 mutual 时TLS，负载均衡器在协商时协商TLS客户端和服务器之间的相互身份验证。当您将 mutual TLS 与 Application Load Balancer 配合使用时，可以简化身份验证管理并减轻应用程序的负载。

通过将 mutual TLS 与 Application Load Balancer 配合使用，您的负载均衡器可以管理客户端身份验证，从而帮助确保只有受信任的客户端才能与您的后端应用程序通信。使用此功能时，Application Load Balancer 会使用来自第三方证书颁发机构 (CA) 的证书或使用 Amazon Private Certificate Authority (PCA) 对客户端进行身份验证，也可以使用吊销检查。应用程序负载均衡器将客户端证书信息传递到后端，您的应用程序可以使用该信息进行授权。通过TLS在 Application Load Balancer 中使用 mutual，您可以使用已建立的库，为基于证书的实体获得内置、可扩展的托管身份验证。

Mutu TLS al for Application Load Balancers 提供了以下两个用于验证 X.509v3 客户端证书的选项：

注意：不支持 X.509v1 客户端证书。

  • 相互TLS直通：当您使用相互直TLS通模式时，Application Load Balancer 会使用HTTP标头将整个客户端证书链发送到目标。然后，通过使用客户端证书链，您可以在您的应用程序中实现相应的负载均衡器身份验证和目标授权逻辑。

  • 相互TLS验证：当您使用相互TLS验证模式时，当负载均衡器协商连接时，Application Load Balancer 会对客户端执行 X.509 客户端证书身份验证。TLS

要开始TLS在 Application Load Balancer 中使用直通方式使用 mutual，您只需要将侦听器配置为接受来自客户端的任何证书即可。要将 mutu TLS al 与验证一起使用，您必须执行以下操作：

  • 创建新的信任存储资源。

  • 上传您的证书颁发机构（CA）捆绑包和（可选）吊销列表。

  • 将信任存储附加到配置为验证客户端证书的侦听器。

有关使用您的 Application Load Balancer 配置相互TLS验证模式的 step-by-step过程，请参阅在 Applicati TLS on Load Balancer 上配置双向。

在开始在 Application Load Balancer TLS 上配置相互之前

在开始在 Applicati TLS on Load Balancer 上配置 mutual 之前，请注意以下几点：

限额

应用程序负载均衡器包括与您的 Amazon 账户中使用的信任存储库、CA 证书和证书吊销列表数量相关的某些限制。

有关更多信息，请参阅 Quotas for your Application Load Balancers。

证书要求

对于用于相互TLS身份验证的证书，应用程序负载均衡器支持以下内容：

  • 支持的证书：X.509v3

  • 支持的公钥：RSA2K — 8K 或 ECDSA secp256r1、secp384r1、secp521r1

  • 支持的签名算法：SHA256，384、512，带有 RSA/SHA256, 384, 512 with EC/SHA 256,384,512 个哈希值带有-RSASSA PSS MGF1

CA 证书捆绑包

以下内容适用于证书颁发机构（CA）捆绑包：

  • 应用程序负载均衡器批量上传每个证书颁发机构（CA）证书捆绑包。应用程序负载均衡器不支持上传单个证书。如果需要添加新证书，则必须上传证书捆绑包文件。

  • 要替换 CA 证书包，请使用ModifyTrustStoreAPI。

证书传递顺序

当您使用相互TLS直通时，Application Load Balancer 会插入标头，将客户端的证书链呈现给后端目标。呈现顺序从叶证书开始，以根证书结束。

会话恢复

在 Application Load Balancer 中使用相互TLS直通或验证模式时，不支持会话恢复。

HTTP 标头

应用程序负载均衡器在使用 mutual 协商客户端连接时使用X-Amzn-Mtls标头发送证书信息。TLS有关更多信息和示例标头，请参阅 HTTP标题和双向 TLS。

CA 证书文件

CA 证书文件必须满足以下要求：

  • 证书文件必须使用PEM（隐私增强邮件）格式。

  • 证书内容必须包含在 -----BEGIN CERTIFICATE----- 和 -----END CERTIFICATE----- 边界内。

  • 注释必须以 # 字符开头，并且不得包含任何 - 字符。

  • 不能有任何空行。

不接受（无效）的证书示例：

# comments

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 01
    Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE
        Validity
            Not Before: Jan 11 23:57:57 2024 GMT
            Not After : Jan 10 00:57:57 2029 GMT
        Subject: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub: 
                    00:01:02:03:04:05:06:07:08
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                00:01:02:03:04:05:06:07:08
            X509v3 Subject Alternative Name: 
                URI:EXAMPLE.COM
    Signature Algorithm: ecdsa-with-SHA384
         00:01:02:03:04:05:06:07:08
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

接受（有效）的证书示例：

  1. 单一证书PEM（已编码）：

    # comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

  2. 多个证书（PEM已编码）：

    # comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
# comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

HTTP标题和双向 TLS

本节介绍应用程序负载均衡器在使用 mut TLS ual 与客户端协商连接时用来发送证书信息的HTTP标头。Application Load Balancer 使用的特定X-Amzn-Mtls标头取决于您指定的相互TLS模式：直通模式或验证模式。

有关应用程序负载均衡器支持的其他HTTP标头的信息，请参阅HTTP标头和应用程序负载均衡器。

HTTP直通模式的标题

对于直通TLS模式下的双向，应用程序负载均衡器使用以下标头。

此标头包含连接中显示的整个客户端证书链的URL编码PEM格式，并带有安全字+=/符。

标头内容示例：

X-Amzn-Mtls-Clientcert: -----BEGIN%20CERTIFICATE-----%0AMIID<...reduced...>do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICATE-----%0AMIID1<...reduced...>3eZlyKA%3D%3D%0A-----END%20CERTIFICATE-----%0A

HTTP验证模式的标题

对于验证模式下的双TLS向，应用程序负载均衡器使用以下标头。

此标头包含叶证书序列号的十六进制表示形式。

标头内容示例：

X-Amzn-Mtls-Clientcert-Serial-Number: 03A5B1

此标头包含颁发者可分辨名称 (DN) 的RFC2253字符串表示形式。

标头内容示例：

X-Amzn-Mtls-Clientcert-Issuer: CN=rootcamtls.com,OU=rootCA,O=mTLS,L=Seattle,ST=Washington,C=US

此标头包含主题可分辨名称 (DN) 的RFC2253字符串表示形式。

标头内容示例：

X-Amzn-Mtls-Clientcert-Subject: CN=client_.com,OU=client-3,O=mTLS,ST=Washington,C=US

此标题包含 ISO86 01 格式的notBefore和notAfter日期。

标头内容示例：

X-Amzn-Mtls-Clientcert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17Z

此标头包含URL叶证书的编码PEM格式，并带有安全字+=/符。

标头内容示例：

X-Amzn-Mtls-Clientcert-Leaf: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0A

广告证书颁发机构 (CA) 使用者名称可帮助客户确定在相互身份验证期间将接受哪些证书，从而增强了TLS身份验证流程。

启用广告 CA 主题名称后，Application Load Balancer 将根据与之关联的信任存储区公布其信任的证书颁发机构 (CAs) 主题名称列表。当客户端通过 Application Load Balancer 连接到目标时，该客户端会收到受信任的 CA 主题名称列表。

在TLS握手期间，当 Application Load Balancer 请求客户端证书时，它会在证书请求消息中包含受信任的 CA 可分辨名称列表 (DNs)。这可以帮助客户选择与通告的 CA 主题名称相匹配的有效证书，从而简化身份验证过程并减少连接错误。

您可以在新的和现有的监听器上启用 “宣传 CA 主题名称”。有关更多信息，请参阅 添加HTTPS监听器。

应用程序负载均衡器的连接日志

Elastic Load Balancing 提供了连接日志，用于捕获有关发送到应用程序负载均衡器的请求的属性。连接日志包含客户端 IP 地址和端口、客户端证书信息、连接结果和正在使用的TLS密码等信息。然后可以使用这些连接日志来查看请求模式和其他趋势。

要了解有关连接日志的更多信息，请参阅 应用程序负载均衡器的连接日志