HAProxy SSL 终止 - 客户端证书扩展密钥使用扩展验证
HAProxy SSL Termination - Client certificate Extended Key usage extension validation
我们正在使用 HAProxy (v1.6.9) 来验证客户端证书 (X.509 v3) 并执行 SSL 终止。我们想要验证客户端证书中的扩展密钥用法和基本约束扩展。通过查看 HAProxy 源代码和 OpenSSL verify 文档，我猜 keyUsage 扩展将得到验证。但是，它是否验证扩展密钥用法以及基本约束扩展？如果没有，那有没有办法在请求头中设置这个信息，并转发给应用程序，让应用程序验证呢？
根据我对 OpenSSL 文档的理解，我们需要在 verify 中设置 "purpose" 选项来验证这些扩展，但我在 HAProxy 的源代码中找不到设置此选项。如有错误请指正
谢谢。
当您使用命令行 verify 或调用 X509_verify_cert 时，您确实需要指定 'purpose' 如果您想要检查它，因为这些操作可以处理用于任何目的的证书链（或目的组合）。对于 SSL/TLS 协议，这是自动处理的，因为 libssl 代码知道它收到并正在检查 cert/chain 是否有 'SSL'（包括 TLS）服务器或客户端；参见 function ssl_validate_cert_chain in ssl/ssl_cert.c——这一行具有指定 'purpose' 的效果。仅对于 1.1.0 版（到目前为止），还根据 anchor/root（除了 ExtendedKeyUsage 扩展）的可选本地信任属性检查目的。
手册页上的声明 "If the -purpose option is not included then no checks [of untrusted cert extensions] are done." 可能具有误导性。如果未指定目的，则不会对 目的 进行任何检查，但无论目的如何，总是会进行一些扩展检查——至少总是针对具有不同 CA 证书的正确链EE证书；对于自签名的 EE 证书，它充当自己的锚点并有效地充当自己的 CA，某些检查不适用。
特别是，如前几段所述，在构建阶段检查 CA（又名颁发者）证书是否 KeyUsage.certSign 和 SKI/issuer/serial 匹配 AKI。在第二阶段，检查所有不受信任的证书的 BasicConstraints（和 now-rare NetscapeCertType）和 KeyUsage.certSign（再次）和 NameConstraints（自 1.0.0 起），如果peer id 已配置（通常仅当对等方是服务器时才有意义，因此不是您的情况，并且仅从 1.0.2 开始）；如果配置（不是默认设置），还有撤销检查（可能涉及扩展）；如果除了所有不受信任的证书上的 ExtKeyUsage 之外还配置了目的检查（它用于 libssl），它会检查 EE 证书的 KeyUsage 和 NetscapeCertType。尽管这里的 EE KeyUsage 检查并不特定于密码组，因此协商的密钥交换方法；在 libssl 中单独检查。
最后阶段除了检查签名和有效期（如上所述）外，还检查 RFC3779 扩展是否使用（几乎从不？）以及是否配置（可能很少见）CertificatePolicies 以及 PolicyMappings、PolicyConstraints 和 InhibitAnyPolicy。
请注意，仅当扩展名的值不一致时，扩展名检查才会失败；如果从给定证书中（由 CA）省略扩展名，它实际上允许与该扩展名相关的所有内容。
HTH.
我们正在使用 HAProxy (v1.6.9) 来验证客户端证书 (X.509 v3) 并执行 SSL 终止。我们想要验证客户端证书中的扩展密钥用法和基本约束扩展。通过查看 HAProxy 源代码和 OpenSSL verify 文档，我猜 keyUsage 扩展将得到验证。但是，它是否验证扩展密钥用法以及基本约束扩展？如果没有，那有没有办法在请求头中设置这个信息，并转发给应用程序，让应用程序验证呢？
根据我对 OpenSSL 文档的理解，我们需要在 verify 中设置 "purpose" 选项来验证这些扩展，但我在 HAProxy 的源代码中找不到设置此选项。如有错误请指正
谢谢。
当您使用命令行 verify 或调用 X509_verify_cert 时，您确实需要指定 'purpose' 如果您想要检查它，因为这些操作可以处理用于任何目的的证书链（或目的组合）。对于 SSL/TLS 协议，这是自动处理的，因为 libssl 代码知道它收到并正在检查 cert/chain 是否有 'SSL'（包括 TLS）服务器或客户端；参见 function ssl_validate_cert_chain in ssl/ssl_cert.c——这一行具有指定 'purpose' 的效果。仅对于 1.1.0 版（到目前为止），还根据 anchor/root（除了 ExtendedKeyUsage 扩展）的可选本地信任属性检查目的。
手册页上的声明 "If the -purpose option is not included then no checks [of untrusted cert extensions] are done." 可能具有误导性。如果未指定目的，则不会对 目的 进行任何检查，但无论目的如何，总是会进行一些扩展检查——至少总是针对具有不同 CA 证书的正确链EE证书；对于自签名的 EE 证书，它充当自己的锚点并有效地充当自己的 CA，某些检查不适用。
特别是，如前几段所述，在构建阶段检查 CA（又名颁发者）证书是否 KeyUsage.certSign 和 SKI/issuer/serial 匹配 AKI。在第二阶段，检查所有不受信任的证书的 BasicConstraints（和 now-rare NetscapeCertType）和 KeyUsage.certSign（再次）和 NameConstraints（自 1.0.0 起），如果peer id 已配置（通常仅当对等方是服务器时才有意义，因此不是您的情况，并且仅从 1.0.2 开始）；如果配置（不是默认设置），还有撤销检查（可能涉及扩展）；如果除了所有不受信任的证书上的 ExtKeyUsage 之外还配置了目的检查（它用于 libssl），它会检查 EE 证书的 KeyUsage 和 NetscapeCertType。尽管这里的 EE KeyUsage 检查并不特定于密码组，因此协商的密钥交换方法；在 libssl 中单独检查。
最后阶段除了检查签名和有效期（如上所述）外，还检查 RFC3779 扩展是否使用（几乎从不？）以及是否配置（可能很少见）CertificatePolicies 以及 PolicyMappings、PolicyConstraints 和 InhibitAnyPolicy。
请注意，仅当扩展名的值不一致时，扩展名检查才会失败；如果从给定证书中（由 CA）省略扩展名，它实际上允许与该扩展名相关的所有内容。
HTH.