Chapter 3. Public Key Infrastructure (PKI)
我们在本章中的意图是给你一个理解PKI如何适应大局的基础。 PKI对于有效使用公钥密码系统非常重要，对于理解和使用SSL协议至关重要。 对PKI的全面讨论超出了本书的范围。 要进行更深入的讨论，我们推荐Russ Housley和Tim Polk（John Wiley＆Sons）编写的“规划PKI：部署公钥基础结构的最佳实践指南”。
在本章中，我们将介绍PKI的功能。
a. 基础设施的各种组件。
b.演示如何成为公共基础设施的一部分，以便希望与我们安全沟通的其他人可以这样做。 c.如何使用OpenSSL命令行工具来建立我们自己的私有基础架构。
3.1 Certificates(证书)
PKI的核心是所谓的证书。 简而言之，证书将绑定一个具有专有名称的公钥。 专有名称就是拥有所绑定的公钥的个人或实体的名称。
证书是使用发行者的私钥签署的，它包含几乎所有必要的信息来验证其有效性。 它包含有关主题，发行人和期限的信息。 缺少的关键部分是发行人的证书。 发行人证书是验证证书有效性的关键部分，因为它包含发行人的公钥，这是验证主体证书签名所必需的。
还会创建证书，并在其中嵌入序列号。 序列号只对证书的颁发者是唯一的。 没有两个由相同的发行人签发的证书应该被分配相同的序列号。 证书的序列号通常用于快速识别证书。
3.1.1 Certification Authorities (证书认证)
证书颁发机构（CA）是颁发证书的组织或公司。 就其性质而言，CA有巨大的责任确保其颁发的证书是合法的。 也就是说，通讯局必须毫无疑问地确保所发出的每一张证书都包含一个由声称已经发出的公开钥匙所发出的公开钥匙。 它必须能够为任何需要发行的证书提供可接受的证据。 否则，CA如何可信？
有两种基本类型的CA。公钥CA证书和私钥CA证书
3.1.1.1 Private Certification Authorities（私钥证书认证）
私钥CA通常是在企业环境中使用的理想选择。 例如，一家公司可以建立自己的电子邮件CA，使用S / MIME作为加密和认证电子邮件的标准。 公司的CA将为每个员工颁发证书，每个员工将配置他们的支持S / MIME的电子邮件客户端，以将公司的CA识别为可信。
对于一个私钥CA来说，验证一个主体的身份通常是相当简单和直接的事情。 例如，在企业环境中使用时，员工是已知的，并且使用从公司人力资源部门获得的信息可以容易地识别他们的身份。 在这样的情况下，据说人力资源部门是一个注册机构（RA）。
3.1.1.2 Public Certification Authorities（公钥证书认证）
需要注意的是，大多数公钥CA提供服务是为了赚钱，而不是简单地使公众受益。 他们仍然有责任去核实一个主体的身份，但实际上并不保证任何事情 - 责任太大，无法提供绝对的保证。 当然，最大限度地验证主体身份符合主管当局的最佳利益。 如果一个证书颁发机构向所有询问（并支付足够的钱）的人颁发证书的声誉，他们将不会长期保持业务，因为没有人会信任它们。
3.1.2 Certificate Hierarchies（证书结构）
如果使用适当的权限创建了已颁发的证书，则由CA颁发的证书可用于颁发和签署另一个证书。 这样，证书可以被链接。 链的根源是根CA的证书。 由于它位于链条的根部，没有其他权限来签署证书，所以根CA签署自己的证书。 这样的证书被称为自签证书。
由于发行人和主体是相同的，所以没有办法以数字方式验证自签名证书的真实性，这就是为什么向他们提供使用它们的软件已经成为惯例。 当他们被包含在应用程序中时，他们通常是通过软件作者通过某种物理手段获得的。 例如，Thawte在其网站上免费提供其根本证书，但强烈建议任何人使用Thawte证书指纹通过电话确认，然后再使用或分发.
为了验证给定证书的真实性和有效性，链中的每个证书也必须从有问题的证书的签发者一直到根证书进行验证。 如果链中的任何证书是无效的，链中的每个证书也必须被视为无效。 无效的证书通常已经过期或被吊销（可能是由于证书被盗用）。 如果证书被篡改并且证书上的签名与应该用于签名的证书不匹配，证书也被认为是无效的。
3.1.3 Certificate Extensions
|
Table 3-1. Common bit settings for the keyUsage extension |
|
|
Purpose of certificate |
Bit settings to use |
|
Certification Authority Certificate |
keyCertSign and cRLSign |
|
Certificate Signing |
keyCertSign |
|
Object Signing |
digitalSignature |
|
S/MIME Encryption |
keyEncipherment |
|
S/MIME Signing |
digitalSignature |
|
SSL Client |
digitalSignature |
|
SSL Server |
keyEncipherment |
3.1.4 Certificate Revocation Lists
一旦颁发证书，通常会投入生产，并分发给许多客户。 如果攻击者损害了相关的私钥，他现在可以使用该证书，即使它不属于他。 假设合适的所有者意识到妥协，应该获得一个带有新密钥对的新证书并投入使用。 在这种情况下，对同一个实体有两个证书 - 两者在技术上是有效的，但不应该被信任。 妥协的证书最终会过期，但与此同时，整个世界将不会相信它呢？
分发CRL时，带宽是一个重要的考虑因素，因为客户需要有合理的当前撤销信息才能正确验证证书。 在一个理想的世界里，一旦CA得到信息，客户就会得到最新的撤销信息。 不幸的是，许多CA仅将CRL分发为一个巨大的列表。 在验证每个证书之前，下载一个巨大的列表可能会容易地增加不可接受的延迟，并且在有很多客户端时会在服务器上施加过度的负载。 因此，CA往往会定期更新他们的CRL，但是在他们了解到关键的妥协之后不会立即更新他们的CRL。 包含在撤销列表中的是下一次更新发布的日期和时间，所以一旦应用程序下载了列表，它就不需要再次这样做，直到它到期。 我们鼓励客户缓存信息（如果客户的存储空间有限，这些信息是不可行的）
CRL的另一个问题是，虽然RFC 2459中有一个标准的正式发布方式，但是这个机制是可选的，而许多更常见的公共CA（如VeriSign）不以这种方式分发它们的CRL。 还有其他分发CRL的标准方法，但是总体问题是不只有一个，所以很多软件应用程序实际上并没有使用CRL。 在各种分发方法中，LDAP最常用作CRL的存储库。 另外，同一台机器甚至本地网络上的多个应用程序可能会对相同的数据感兴趣，并要求在短时间内多次从CA中查询。
3.1.5 Online Certificate Status Protocol
www.OpenValidation.org
3.2 Obtaining a Certificate
在获得证书之前，首先需要确定证书的用途。 公共和私人的各种CA提供了许多不同类型的证书。 从公共CA获得三种不同类型证书的必要性。
正如我们所提到的，有许多不同类型的证书，每个用于不同的目的。 威瑞信的产品范围从用于S / MIME的个人证书到更复杂的企业解决方案。 我们将了解如何获得S / MIME的个人证书，用于签名软件的密码证书，以便用户验证证书是否来自您，以及用于保护您的网站以获取电子商务等应用程序的证书。
3.2.1 Personal Certificates
获取个人证书的第一步是访问威瑞信的网站http://www.verisign.com/，并按照主页上的链接“安全电子邮件”，该链接列在“家庭和家庭办公室 “产品，以数字身份证登记表。 我们不会在这里列出所有的链接，不仅因为它们可能会发生变化，而且因为网站上有很多值得一读的信息，包括有关如何使用证书的信息 已发出。 一旦您填写并提交了注册表格，威瑞信将发送一封自动电子邮件到您提供的地址，说明如何“取得”证书
关于报名表格的第一组问题是不言自明的。 您输入的名字和姓氏将是您的数字身份证在VeriSign目录服务中的列表。 您输入的电子邮件地址应该是您使用数字身份证的电子邮件地址。 它成为证书的专有名称。 它也被列在目录中的名字和姓氏的旁边。 威瑞信也将使用该地址来验证其有效性，方法是向该地址发送一封自动电子邮件，并说明如何检索已发出的证书。
接下来，VeriSign将要求一个质疑短语，用于保护证书。 该短语将提供给你和VeriSign。 你不应该与其他人分享！ VeriSign将使用该短语来验证您是证书的所有者，当您请求撤销，更新或替换证书时。 一定要选择一个你能够记住的短语，但是一个不会轻易被熟悉你的人猜到的短语。
VeriSign会根据您浏览器的信息为证书选择默认密钥长度并发给您。 您不需要更改为您选择的密钥长度，除非您使用Netscape或Microsoft产品以外的其他方式访问您的电子邮件，在这种情况下，您的电子邮件软件或软件供应商的文档应该已经建议 你在正确的设置选择。
如果您使用的是Microsoft Internet Explorer，则默认情况下，您的私钥将不受保护。 也就是说，一旦您将其安装在您的电子邮件软件中，就不需要输入任何密码或密码来访问它。 如果您选择以这种方式保护您的私钥不受保护，则必须确保您的证书的私钥不被泄露。 一般来说，将私钥置于不受保护的位置不是一个好主意，因此VeriSign提供了两种保护方法。 低安全性的默认设置是中级安全性，每次访问私钥时都需要您的批准。 在中等安全的情况下，您仍然不需要输入密码或密码来解锁私钥。 高安全性要求您输入密码或密码以在每次访问时解锁密钥。
请记住，任何获得您私钥访问的人都可以使用您的证书来伪装你。 当一个电子邮件与您的私钥签署，人们将信任它，这可能会造成灾难性的影响，如果你的密钥泄露。 任何有权访问您的私钥的人也将能够解密用您的公钥加密的电子邮件。 当然，您的证书可以被吊销，但正如我们前面所讨论的，撤销证书没有任何影响，如果它的撤销状态没有被检查。 考虑到这一点，特别是对于移动用户，我们强烈建议您选择高安全性。
最后，您必须阅读并接受VeriSign的用户协议和隐私政策。 如果您使用的是Microsoft Internet Explorer，并选中了用于保护证书的复选框，则会显示一个对话框，以选择您希望应用于证书的安全级别。 在一个小时左右的时间内，您将收到VeriSign发送的一封电子邮件，其中包含您在“注册表”中输入的地址，其中包含有关如何从VeriSign“获取”您的证书的说明。 在电子邮件中包含一个URL和一个PIN，两者都需要从VeriSign获得证书。 您应该使用相同的机器和浏览器来检索证书，就像您要求的那样。
这里的所有都是它的！ 一旦您从威瑞信中检索到您的证书，请按照VeriSign站点上的说明在Netscape或Microsoft Internet Explorer中使用证书。 同样，如果您使用其他软件访问您的电子邮件，请按照供应商的指示启用证书。 现在您已经准备好开始发送和接收安全的电子邮件了！
3.2.2 Code-Signing Certificates
获取代码签名证书并不像获得个人证书那么简单快捷。 他们也相当昂贵，但是再一次，他们并不是真正用于日常的个人用户。 在撰写本文时，VeriSign为各种类型的程序提供了六种不同类型的代码签名证书。 您必须确保为要签名的代码获取适当的证书，因为不同类型的证书可能无法与其他类型的代码正常工作。 例如，Microsoft Authenticode证书仅适用于Microsoft的Internet Explorer浏览器。 对于Netscape浏览器，您需要获取Netscape对象签名证书。 代码签名证书的可用类型被列为获取代码签名证书的过程的一部分。 选择类型是获取代码签名证书的第一步.
代码签名证书的类型决定了向VeriSign请求获取请求的具体要求。 例如，对于Microsoft Authenticode Digital ID，大部分工作都通过Microsoft的Internet Explorer实现自动化，而Sun Java签名数字身份证则要求您使用Sun的Java工具生成证书请求，并与请求一起提交。 对于每种类型的证书，威瑞信都提供完整的说明，说明需要哪些与代码签名证书相关的信息，以及如何获取并提供给VeriSign。
虽然每种类型的代码签名证书对于提出请求都有其特定的要求，但是也有一些共同的要求必须被满足。 大部分要求都是不言自明的，例如联系和支付信息。 每个证书还必须有关于谁拥有证书的信息。 这些信息包括公司或组织的名称以及它从事业务的地点。 例如，从美国开展业务的公司将被要求提供其所在的城市和州。
当然，在这种情况下，VeriSign也有非常重要的需求来验证他们是否将证书颁发给合法拥有该证书的人。 VeriSign验证此信息的最快最容易的方法是使用Dun＆Bradstreet D-U-N-S号码。 提供这些信息是可选的，但是替代方案需要您和VeriSign两方面的更多时间和精力。 如果您没有或不想使用D-U-N-S号码，则可以选择邮寄或传真您的营业执照，公司章程或合伙文件以及您的代码签名证书申请。
一旦提交了您的请求（包括任何适当的文档），VeriSign将对其进行审核。 如果一切顺利，将提供代码签名证书并提供有关如何检索证书以便分发和使用的说明。 与个人证书不同，对代码签名证书的请求由实际的活人进行审查和验证，因此不能立即提供。 取决于VeriSign的工作量，发行证书可能需要几天的时间，但VeriSign加急请求额外收费。
3.2.3 Web Site Certificates
获取用于保护网站的证书的过程（VeriSign称其为安全的服务器证书）与获取代码签名证书的证书的过程类似。 许多相同的信息是必需的，虽然有一些值得注意的差异。 显然，主要的区别之一是所提供证书的类型。 尽管代码签名证书根据将要签名的代码类型（例如，Netscape插件与Java小程序）而不同，但安全服务器证书是40位或128位SSL证书之一。 也就是说，网站证书明确地限制了应与证书一起使用的对称密钥的大小。 我们建议您坚持使用128位证书，因为40位对称密钥被广泛认为是无法接受的弱。
无论您计划使用哪种服务器软件，都必须遵循有关如何生成证书签名请求（CSR）的说明。 由于目前可用的服务器种类繁多，因此我们在这里提供有关如何执行此操作的说明并不实际。 VeriSign对其网站上的许多更受欢迎的服务器提供了说明。 您生成的CSR也将生成密钥对。 虽然您必须将CSR提交给VeriSign才能颁发证书，但您应该保留私钥。 不应将其发送给VeriSign或任何其他人。
与代码签名证书一样，您也必须向VeriSign提供可以接受的证据，证明您有权使用您正在请求的证书。 提供此证明的选项是相同的 - 提供一个D-U-N-S号码或上述可接受文件之一的复印件。 另外，安全服务器证书绑定到域名。VeriSign将仅向域名的注册所有者颁发证书。 这意味着，如果域名由公司实体拥有，您必须是该公司的员工。
一旦提交了您的请求（包括任何适当的文档），VeriSign将对其进行审核。
3.3 Setting Up a Certification Authority
建立一个CA似乎是一项艰巨的任务，但并不一定如此。 有一些免费和商业CA包可用。 OpenSSL命令行工具甚至提供了设置可在小型组织中使用的最小CA所需的全部功能。 OpenSSL命令行工具的CA功能最初只是一个示例，但其中两个更受欢迎的免费CA包（OpenCA和pyCA）将其用作其基础。 在撰写本文时，这些工具还相当不成熟，并且OpenSSL命令行工具没有提供（LDAP存储是显着的例外）。
在本节中，我们将通过使用OpenSSL命令行工具来设置CA的必要步骤。 我们将向您展示如何创建供CA使用的自签名根证书，如何构建OpenSSL可用于您的CA的配置文件以及如何使用CA颁发证书和CRL。 由于OpenSSL的命令行CA功能主要是作为如何使用OpenSSL构建CA的示例，因此我们不建议您尝试在大型生产环境中使用它。 相反，它应主要用作学习PKI如何工作的工具，并作为使用专门为生产环境使用而设计的工具构建真实CA的起点。
3.3.1 Creating an Environment for Your Certification Authority
a.创建root目录
b.创建certs（存放证书）和private子文件
c.第一个文件用于跟踪用于颁发证书的最后一个序列号（serial）。
d.第二个文件是一个跟踪由CA颁发的证书的排序数据库（index.txt）。
Example 3-1. Creating the CA's environment
# mkdir /opt/exampleca
# cd /opt/exampleca
# mkdir certs private
# chmod g-rwx,o-rwx private
# echo '01' > serial
# touch index.txt
备注：/opt/exampleca为存放CA根目录。
3.3.2 Building an OpenSSL Configuration File
还有一个文件需要创建，但是它比我们已经创建的前两个文件复杂得多。 这是OpenSSL命令行工具将用于获取有关如何颁发证书的信息的配置文件。 我们可以设想跳过创建这个文件并使用OpenSSL的默认设置，这实际上是相当理智的，但是通过使用一个配置文件，我们省去了一些向OpenSSL发出命令的工作。 我们在第2章中简要地讨论了配置文件及其使用方法。现在是时候创建一个我们自己的配置文件并使用它。
CA函数的OpenSSL命令恰好命名为ca，只包含一个键：default_ca。
default_crl_days : 对应crldays命令
default_days： 对应days命令
default_md： 对应md命令
openssl.cnf文件
[ ca ]
default_ca = exampleca
[ exampleca ]
dir = /opt/exampleca
certificate = $dir/cacert.pem
database = $dir/index.txt
new_certs_dir = $dir/certs
private_key = $dir/private/cakey.pem
serial = $dir/serial
default_crl_days = 7
default_days = 365
default_md = md5
policy = exampleca_policy
x509_extensions = certificate_extensions
[ exampleca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = supplied
organizationName = supplied
organizationalUnitName = optional
[ certificate_extensions ]
basicConstraints = CA:false
Example 3-3. Telling OpenSSL where to find our configuration file
# OPENSSL_CONF=/opt/exampleca/openssl.cnf
# export OPENSSL_CONF
3.3.3 Creating a Self-Signed Root Certificate
[ req ]
default_bits = 2048
default_keyfile = /opt/exampleca/private/cakey.pem
default_md = md5
prompt = no
distinguished_name = root_ca_distinguished_name
x509_extensions = root_ca_extensions
[ root_ca_distinguished_name ]
commonName = Example CA
stateOrProvinceName = Virginia
countryName = US
emailAddress = ca@exampleca.org
organizationName = Root Certification Authority
[ root_ca_extensions ]
basicConstraints = CA:true
# openssl req -x509 -newkey rsa -out cacert.pem -outform PEM
备注：OPENSSL_CONF environment variable first so that OpenSSL can find your configuration file!
3.3.4 Issuing Certificates
Example 3-5. Output from generating a self-signed root certificate
openssl req -x509 -newkey rsa -out cacert.pem -outform PEM
Example 3-6. Generating a certificate request
$ openssl req -newkey rsa:1024 -keyout testkey.pem -keyform PEM -out testreq.pem
Example 3-7. The resulting certificate request
$ openssl req -in testreq.pem -text -noout
Example 3-8. Issuing a certificate from a certificate request
$ openssl ca -in testreq.pem
testreq.pem :包含证书请求
testkey.pem :包含与证书请求中嵌入的公钥相匹配的私钥。
3.3.5 Revoking Certificates
Example 3-9. Revoking a certificate
# cp certs/01.pem testcert.pem
# openssl ca -revoke testcert.pem
# openssl ca -gencrl -out exampleca.crl
openssl ca -gencrl -config openssl.conf -out exampleca.crl