☰

如何正确设置 openssl CA 以生成 ssl 客户端证书

tag-icon • tag-icon openssl
如何正确设置 openssl CA 以生成 ssl 客户端证书

我正在配置我的第一个 CA。它的目的是为我们的客户颁发证书，客户将使用它们通过 https 访问我们的 EDI 服务。所以我需要生成 SSL 客户端证书。到目前为止，签署证书的整个过程都正常，证书可以成功用于访问我们的服务，但我担心一件事：

生成的证书用途是通用的：

$ openssl x509 -purpose  -noout -in client.crt.pem
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

我觉得在我的案例中，除了 SSL 客户端和 S/MIME 签名之外，不应该有其他用途。我错了吗？这应该保持原样吗？

如果我是正确的并且我应该禁用其他目的，那么我应该在 openssl.cnf 配置中输入什么？

以下是我当前的配置（略微删减了一下）：

[ CA_edi ]
# here was directory setup and some other stuff, cut it for clarity
x509_extensions = usr_cert      # The extentions to add to the cert

name_opt    = ca_default        # Subject Name options
cert_opt    = ca_default        # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# stripped rest of config about validity days and such

[ usr_cert ]

basicConstraints=CA:FALSE
nsCertType = client, email
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

我做错了什么，导致生成的证书允许服务器使用？

答案1

您对“CRL 签名”、“任何目的 CA”和“OCSP 助手”的关注是正确的，这些通常保留用于 CA 证书或专门为签署证书吊销列表（CRL，无效证书列表）或运行 OCSP 服务器（类似于 CRL，但是提供证书有效性状态的在线服务）而颁发的证书。

相关的 OpenSSL 文档页面是x509 命令和x509v3_配置

这是我用于生成客户端证书的 OpenSSL 配置：

[user]
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth,emailProtection
subjectAltName=email:copy
crlDistributionPoints = URI:http://www.rgweb.org/ca/rgweb-ca.crl
authorityKeyIdentifier=keyid:always
authorityInfoAccess = caIssuers;URI:http://www.rgweb.org/ca/rgweb-ca.cer

我将逐行向您介绍：

设置basicConstraints为关键，这意味着“如果您不理解这一点，请拒绝此证书”，并指定该证书是不是 CA即使有人使用软件根据该证书颁发证书，也不会被信任。

扩展密钥的使用并非必不可少，但有些软件要求它存在并列出特定用途。这列出了客户端身份验证（您正在谈论的内容）以及 S/MIME 电子邮件签名和加密；如果您不需要它，您可以安全地删除 S/MIME 用途。

subjectAltName允许您包含无法包含在字段中的主题信息subject。它还用于 Web 服务器证书，以包含证书可用于的域名，而不是主题的通用名称属性中指定的域；这些证书称为 SAN（主题备用名称）证书。通常的做法是将电子邮件地址包含在中，subjectAltName而不是主题中；您根本不必包含电子邮件地址，并且可以省略扩展名。

crlDistributionPoints列出颁发机构的 CRL 可用的地方；它告诉试图验证证书的软件“从这里可以查看此证书是否仍然有效。”对于 Internet 使用，URLhttp://可能是最好的（CRL 是数字签名的，因此不需要https，并且可能会导致信任循环问题）。

authorityKeyIdentifier通常是颁发 CA 公钥的 SHA-1 哈希值（尽管也可能是其他值）。如果包含此扩展，则值subjectKeyIdentifier必须与颁发 CA 证书中的值匹配。

authorityInfoAccess有点像crlDistributionPoints，但它指定了从哪里获取颁发 CA证书而不是 CRL。如果您有很长的信任链，这将非常有用：例如 CA-1 颁发 CA-2，CA-2 颁发 CA-3，CA-3 颁发证书；尝试验证证书的软件可以使用此扩展获取 CA-3 证书，然后使用该证书中的值获取 CA-2 证书等。通常，证书链（在本例中为 CA-2 证书和 CA-3 证书）与主题的证书捆绑在一起（例如在 SSL 事务或 S/MIME 电子邮件中）。我不知道有任何软件使用此扩展，但我也不知道它不常用。它通常包含在证书中。

在所有这一切中，你真正需要和basicConstraints；extendedKeyUsage基本约束真的，真的必须至关重要（或者您刚刚发出了 CA 证书！），而扩展密钥的使用通常并不重要。

相关内容