☰

证书颁发机构和中级 CA

tag-icon • tag-icon ssl certificate openssl
证书颁发机构和中级 CA

我想设置一个证书链，顶部有一个自签名的“根”CA，它签署子 CA，然后子 CA 可以签署客户端和服务器证书。在设置时openssl.cnf，我注意到一个keyUsage参数，显然需要将其设置为密钥应该用于的任何用途。虽然参数值已记录在案，但我找不到有关在某些情况下使用哪些参数的任何信息。

这些值的含义是什么keyUsage？在下列情况下我应该使用什么？

  • 自签名根 CA
  • 中级 CA（可以签署其他 CA）
  • 中级 CA（无法签署其他 CA）
  • 非 CA 证书

此外，是否需要使用某些值指定其他扩展，例如nsCertType？

答案1

任何 CA 证书（无论是根证书还是中间证书）都必须具有扩展keyCertSign名。如果您还想使用 CA 证书签署吊销列表 (CRL)（您通常确实希望这样做），那么您还必须添加cRLSign。对于 CA 证书，可以且应该避免使用任何其他 keyUsage。

openssl 接受的值列表是记录在这里。

对于终端实体证书，您可以使用 openssl 记录的任何其他 keyUsage，只需确保不包含上面提到的 CA 扩展即可。从安全角度来看，您不应使用比必要更多的 keyUsage（尤其是建议使用单独的证书进行签名和加密），但这不是严格的要求。

请注意，除了经典的 keyUsages 之外，还有extendedKeyUsage(EKU) 扩展，它不限于 RFC 中的预定义值，理论上可以保存任何你喜欢的 OID。已知值例如用于签署时间戳或 OCSP 响应的证书。

您不需要使用nsCertType。这些以及所有其他 ns* 扩展都是 Netscape 很久以前定义的，不应再使用。您可能找不到任何仍在使用它们的软件。

对于其他扩展，唯一绝对需要的是basicConstraints具有布尔CA标志的扩展，您必须相应地设置该标志。 我们也强烈推荐 authorityKeyIdentifier 和 subjectkeyIdentifier 扩展。

答案2

风俗openssl.cnf（信息） 和如何使用，所需命令从第 430 行开始

证书颁发机构和中级 CA

自签名 CA

  • 密钥用法： cRLSign，，digitalSignature​keyCertSign
    （不应包含任何其他 KU 且不应包含 EKU）
  • V3 简介： 
    [ v3_ca ]
basicConstraints        = critical, CA:TRUE
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, cRLSign, digitalSignature, keyCertSign
subjectAltName          = @alt_ca

中级 CA

  • 密钥用法： cRLSign，，digitalSignature​keyCertSign
    （不应包含任何其他 KU 且不应包含 EKU）
  • V3 简介： 
    [ v3_ica ]
basicConstraints        = critical, CA:TRUE, pathlen:0
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, cRLSign, digitalSignature, keyCertSign
subjectAltName          = @alt_ica
    • 在哪里pathlen:等于其可以签署的 CA/ICA 数量
      （如果未指定 pathlen/设置数字，它可以签署无限/指定数量的 CA/ICA）


非 CA 证书

VPN/Web 服务器

  • 密钥用法： digitalSignature，，keyEncipherment​keyAgreement
  • V3 简介： 
    [ v3_vpn_server ]
basicConstraints        = critical, CA:FALSE
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, digitalSignature, keyEncipherment, keyAgreement 
extendedKeyUsage        = critical, serverAuth
subjectAltName          = @alt_vpn_server

VPN 客户端

  • 密钥用法： digitalSignature，keyEncipherment
  • V3 简介： 
    [ v3_vpn_client ]
basicConstraints        = critical, CA:FALSE
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, digitalSignature, keyEncipherment
extendedKeyUsage        = critical, clientAuth
subjectAltName          = @alt_vpn_client


keyUsage

仅限加州

keyCertSign

  • 主体公钥用于验证证书上的签名
  • 此扩展只能用于 CA 证书

cRLSign

  • 主体公钥用于验证撤销信息（例如 CRL）上的签名
  • 此扩展只能用于 CA 证书

digitalSignature

  • 证书可用于应用数字签名
    • 数字签名通常用于实体认证和数据来源认证以及完整性

nonRepudiation

  • 证书可用于对上述数据进行签名，但证书公钥可用于提供不可否认服务
    • 这可以防止签名实体错误地否认某些行动

keyEncipherment

  • 证书可用于加密对称密钥，然后将其传输给目标
    • 目标解密密钥，随后使用它来加密和解密实体之间的数据

dataEncipherment

  • 证书可用于加密和解密实际的应用数据

keyAgreement

  • 证书允许使用密钥协商协议与目标建立对称密钥
  • 然后可以使用对称密钥来加密和解密实体之间发送的数据

encipherOnly

  • 公钥仅用于在执行密钥协议时加密数据
    • 要求 KU： keyAgreement

decipherOnly

  • 公钥仅用于在执行密钥协议时解密数据
    • 要求 KU： keyAgreement

RFC 5280[4.2.1.3]

id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }

  • 位串是十六进制的 
    keyUsage ::= BIT STRING {
  digitalSignature    (0),
  nonRepudiation      (1),
  keyEncipherment     (2),
  dataEncipherment    (3),
  keyAgreement        (4),
  keyCertSign         (5),
  cRLSign             (6),
  encipherOnly        (7),
  decipherOnly        (8)
}


extendedKeyUsage

CA/ICA 不应指定任何 EKU

serverAuth

  • 所有 VPN/Web 服务器都应使用此 EKU 进行签名
    （这取代了nscertype选项，如ns代表nscertypeNetScape [浏览器]）
    • SSL/TLS VPN/Web 服务器身份验证 EKU，区分客户端可以进行身份​​验证的服务器
    • 要求 KU： digitalSignature，keyEncipherment或者keyAgreement

clientAuth

  • 所有 VPN 客户端都必须使用此 EKU 进行签名
    • SSL/TLS Web/VPN 客户端身份验证 EKU 仅将客户端区分为客户端
    • 要求 KU： digitalSignature和/或keyAgreement

codeSigning

  • 代码签名
    • 要求 KU： digitalSignature、nonRepudiation和/或keyEncipherment或者keyAgreement

emailProtection

  • 通过 S/MIME 进行电子邮件保护，允许您发送和接收加密电子邮件
    • 要求 KU： digitalSignature，keyEncipherment或者keyAgreement

timeStamping

  • 可信时间戳
    • 要求 KU： digitalSignature，nonRepudiation

OCSPSigning

  • OCSP 签名
    • 要求 KU： digitalSignature，nonRepudiation

msCodeInd

  • Microsoft 个人代码签名 (authenticode)
    • 要求 KU： digitalSignature，keyEncipherment或者keyAgreement

msCodeCom

  • 微软商业代码签名（authenticode）
    • 要求 KU： digitalSignature，keyEncipherment或者keyAgreement

mcCTLSign

  • Microsoft 信任列表签名
    • 要求 KU： digitalSignature，nonRepudiation

msEFS

  • Microsoft 加密文件系统签名
    • 要求 KU： digitalSignature，keyEncipherment或者keyAgreement

!!! 不应被利用 !!!

ipsecEndSystem，ipsecTunnel，&ipsecUser

  • 这些值于 1999 年指定，但其语义从未得到明确定义
  • RFC 4945：这三个 EKU 值的使用已过时，并在本规范中明确弃用[5.1.3.12]

ipsecIKE

  • IPSec 互联网密钥交换
    （我认为这与上面三点是同样的情况）
  • 需要进行研究来确定是否也不再使用此 EKU
    （clientAuth可用于 IPSec VPN 客户端证书）

RFC 5280[4.2.1.12]

anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

  • id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

    • id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
      • TLS 服务器身份验证
        • KU 位适用于：
          digitalSignature，keyEncipherment或者keyAgreement

    • id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
      • TLS 客户端身份验证
        • KU 位适用于：
          digitalSignature和/或keyAgreement

    • id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
      • 可下载可执行代码的签名
        • KU 位适用于：
          digitalSignature

    • id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
      • 电子邮件保护
        • KU 位适用于：
          digitalSignature，nonRepudiation和/或keyEncipherment或者keyAgreement

    • id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
      • 将对象的哈希值与时间绑定
        • KU 位适用于：
          digitalSignature和/或nonRepudiation

    • id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
      • 签署 OCSP 响应
        • KU 位适用于：
          digitalSignature和/或nonRepudiation

相关内容