如何正确设置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

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

您不必担心“ CRL签名”，“任何目的CA”和“ OCSP帮助器”，这些通常是为CA证书或专门为签署证书吊销列表（CRL）颁发的证书保留的。无效）或运行OCSP服务器（类似于CRL，但提供证书有效状态的在线服务）。

相关的OpenSSL文档页面适用于x509命令和x509v3_config

这是我用于生成客户端证书的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使用，http://URL可能是最好的（CRL是经过数字签名的，因此不需要https，这可能会导致信任循环问题）。

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

authorityInfoAccess有点像，crlDistributionPoints但是它指定了在何处获得颁发CA 证书而不是CRL。如果您拥有长久的信任链，这将非常有用：例如CA-1颁发CA-2，CA-3颁发证书； CA-1颁发CA-3，证书颁发于CA3。尝试验证证书的软件可以使用此扩展名获取CA-3证书，然后使用该证书中的值获取CA-2证书等。通常，证书链（在这种情况下为CA-2证书）和CA-3证书）与主题的证书捆绑在一起（例如，通过SSL交易或S / MIME电子邮件）。我不知道有任何使用此扩展程序的软件，但我也不知道它也不常用。它通常包含在证书中。

所有这一切，你只有真正需要的basicConstraints和extendedKeyUsage; 基本约束真的，真的必须是至关重要的（或者你刚刚发放的CA证书！），和扩展密钥用法一般是没有的。