用于ECDH密钥交换。EKU作为扩展字段要强调其场景化特性。需要区分TLS服务器身份验证（id-kp-serverAuth）和客户端认证（id-kp-clientAuth）的不同OID，这是双向认证的关键理解SSL证书中的密钥用途（Key Usage， KU）和扩展密钥用途（Extended Key Usage， EKU）对于确保证书被正确使用和安全至关重要。它们共同定义了证书中包含的公钥（以及对应的私钥）可以用于哪些密码学操作。
下面是两者的详细解释和区别：
一、密钥用途（Key Usage - KU）
1. 定义与目的：
KU是一个基本的X.509证书扩展（在RFC 5280中定义）。
它定义了公钥可以执行的基础密码学操作。
其主要目的是限制密钥的滥用，防止密钥被用于其设计目的之外的操作（例如，防止一个仅用于签名的密钥被错误地用于加密）。
它是一个位图（Bitmask），包含一组预定义的标志位（Flags）。
2. 常见的KU标志位：
digitalSignature： 密钥可用于验证数字签名（不包括证书或CRL签名的特定情况）。这是TLS客户端和服务器在握手期间进行身份验证（例如，CertificateVerify消息）时最常用的标志。
nonRepudiation (或 contentCommitment)： 密钥可用于创建具有法律可执行性的数字签名（例如，签署合同）。比digitalSignature更具法律意义。
keyEncipherment： 密钥可用于加密对称密钥或其他密钥材料（例如，在RSA密钥交换中，客户端使用服务器的公钥加密预主密钥）。
dataEncipherment： 密钥可用于直接加密用户数据（而不仅仅是密钥）。在TLS/SSL中很少使用，因为TLS通常使用对称加密来保护数据。
keyAgreement： 密钥可用于密钥协商协议（例如，Diffie-Hellman, ECDH）。当使用基于（EC）DHE的密钥交换时，服务器的证书需要此标志（如果证书公钥参与协商）。在基于RSA的密钥交换中不需要。
keyCertSign： 密钥可用于签署其他证书。这是CA证书的关键标志。终端实体（End-Entity）证书绝对不能设置此位。
cRLSign： 密钥可用于签署证书吊销列表（CRL）。同样，只有CA证书需要此标志。
encipherOnly： 仅在与keyAgreement一起使用时才有意义，表示密钥仅用于加密（在密钥协商期间）。
decipherOnly： 仅在与keyAgreement一起使用时才有意义，表示密钥仅用于解密（在密钥协商期间）
3. 在SSL/TLS中的关键点：
服务器证书：
对于RSA密钥交换：通常需要digitalSignature和keyEncipherment（因为服务器私钥既用于签名身份验证，也用于解密预主密钥）。
对于（EC）DHE密钥交换：通常需要digitalSignature和keyAgreement（服务器私钥用于签名身份验证和（EC）DH密钥协商）。
对于ECDSA签名证书（配合（EC）DHE）：通常只需要digitalSignature（签名身份验证由ECDSA私钥完成，密钥协商由临时的（EC）DHE密钥对完成）。
客户端证书： 主要用于身份验证，通常只需要digitalSignature（有时也可能需要keyEncipherment，取决于具体实现和协议）。
CA证书： 必须设置keyCertSign（通常也会设置cRLSign）。
二、扩展密钥用途（Extended Key Usage - EKU）
1. 定义与目的：
EKU是一个扩展的X.509证书扩展（在RFC 5280中定义）。
它定义了公钥可以用于的特定应用程序或协议目的，是对基本KU的更精细化限制和说明。
其主要目的是进一步限定证书的使用场景。例如，明确一个证书只能用于服务器身份验证，或者只能用于客户端身份验证，或者只能用于代码签名。
它包含一个或多个对象标识符（OID） 列表。
2. 常见的EKU OID：
服务器身份验证： id-kp-serverAuth (1.3.6.1.5.5.7.3.1) - 这是HTTPS/SSL服务器证书的绝对要求。表示此证书可用于验证TLS/SSL服务器身份。
客户端身份验证： id-kp-clientAuth (1.3.6.1.5.5.7.3.2) - 表示此证书可用于验证TLS/SSL客户端身份（双向认证）。
代码签名： id-kp-codeSigning (1.3.6.1.5.5.7.3.3) - 表示此证书可用于签署可执行代码、脚本或固件。
电子邮件保护： id-kp-emailProtection (1.3.6.1.5.5.7.3.4) - 表示此证书可用于签署和/或加密电子邮件（S/MIME）。
时间戳： id-kp-timeStamping (1.3.6.1.5.5.7.3.8) - 表示此证书可用于签署时间戳令牌（RFC 3161）。
OCSP签名： id-kp-OCSPSigning (1.3.6.1.5.5.7.3.9) - 表示此证书可用于签署OCSP响应。
智能卡登录： id-kp-smartcardlogon (1.3.6.1.4.1.311.20.2.2) - 微软定义的OID，用于智能卡登录Windows域。
文档签名： id-kp-documentSigning (1.3.6.1.4.1.311.10.3.12) - 微软定义的OID，用于签署文档。
3. 在SSL/TLS中的关键点：
服务器证书： 必须包含id-kp-serverAuth OID。浏览器和其他TLS客户端会严格检查此EKU。如果缺失或不匹配，连接会被中止（通常报ERR_SSL_VERSION_OR_CIPHER_MISMATCH或类似错误）。
客户端证书： 通常需要包含id-kp-clientAuth OID，以便服务器知道该证书被授权用于客户端身份验证。
多用途证书： 一个证书可以包含多个EKU OID（例如，同时包含serverAuth和clientAuth），表示该证书可用于多种用途。但出于安全最佳实践，通常建议为不同用途颁发专用证书。
三、KU 与 EKU 的关系与区别
密钥用途 (Key Usage - KU)与扩展秘钥用途(Extended Key Usage - EKU)不通。定义秘钥限制不同，场景操作不同，EKU 依赖于KU。没有秘钥会握手失败，在SSL/TLS中至关重要，证书缺少必需的KU将导致握手失败。在SSL证书中至关重要，服务器证书缺少serverAuth EKU将导致连接失败。
示例
digitalSignature, keyEncipherment, keyAgreement, keyCertSign
id-kp-serverAuth, id-kp-clientAuth, id-kp-codeSigning
四、总结与最佳实践
1. 两者都不可或缺： 在SSL/TLS证书（尤其是服务器证书）中，KU和EKU都是强制且关键的扩展。它们协同工作，共同定义了证书的有效用途。
2. 服务器证书核心要求：
KU： 必须包含执行身份验证和密钥交换所需的标志（如digitalSignature + keyEncipherment（RSA）或 digitalSignature + keyAgreement（DHE/ECDHE））。
EKU： 必须包含id-kp-serverAuth (1.3.6.1.5.5.7.3.1)。
3. 客户端证书要求：
KU： 通常需要digitalSignature。
EKU： 通常需要id-kp-clientAuth (1.3.6.1.5.5.7.3.2)。
4. CA证书要求：
KU： 必须包含keyCertSign（通常也包含cRLSign）。
EKU： 通常不设置任何EKU（或者设置anyExtendedKeyUsage，但强烈不推荐）。CA证书的用途由KU的keyCertSign/cRLSign明确界定。
5. 精确性原则： 应尽可能精确地设置KU和EKU，只包含证书实际需要的用途（遵循最小权限原则），避免使用anyExtendedKeyUsage OID（除非有非常充分的理由），以提高安全性。
6. 验证： TLS客户端（浏览器）和服务器在握手过程中会严格验证证书的KU和EKU是否符合其预期的用途（服务器认证或客户端认证）。如果验证失败，连接将被终止。
因此用户理解并正确配置Key Usage和Extended Key Usage是确保证书安全有效运行在SSL证书环境中的基石。签发证书时（无论是公共CA还是私有PKI），必须根据证书的预期角色仔细设置这些扩展。
