密码学专题 证书和CA指令 证书和CA功能概述

为什么需要证书

• 实现了公钥和私钥的相互验证，但是任何人都可以生成很多的密钥对，密钥对并没有关联实体身份，因此诞生可数字证书
• 前提是CA是所有用户都信任的
• 用户需要将自己的信息和公钥交给CA进行认证生成一个属于自己并被其与用户认可的数字证书，然后双方通信的时候使用与数字证书里面对应的公钥进行数字签名

证书生命周期

证书申请

• 证书的声明周期是指证书申请到证书被吊销整个过程，这个过程中涉及到证书的申请、颁发、使用和其余各个管理方面的问题
• 最常用的是RSA密钥和DSA密钥，算法的类型和具体的使用场景相关，比如用于密钥交换目的的证书就不可以使用DSA密钥，只能使用RSA密钥
• 生成密钥对可以使用OpenSSL的genrsa和gendsa命令，还可以使用req指令
• 申请的时候需要涉及到 用户需要填写哪些信息 以及如何对填写的信息进行格式化操作
• PKCS#10标准规定了这些相关的格式。其基本思想是用户根据要求填写这些信息，然后将这些信息和用户产生的公钥一起用相应的私钥签名发给CA验证，这可以使得CA确认这些信息是申请的用户自己发送的，因为CA可以把证书请求中的公钥拿出来验证这个证书请求的签名。
• OpenSSL提供了req指令帮助我们填写和生成这个格式复杂的证书请求，当然，根据不同CA的要求，你可能需要更改OpenSSL的配置文件(默认是openssl.cnf)中证书请求相关的部分配置。完成这些工作，你就可以把证书请求交给CA，OpenSSL的CA指令，执行操作只要几秒到几百毫秒

证书颁发

• 第一步就是验证证书请求上的签名是否正确，也就是说，确保公钥对应的私钥就在申请者手中并且申请信息是正确的没有被更改的。然后就要仔细审查证书请求里的用户信息，这工作一般由CA管理人员完成，管理人员应该依据管理规范(一个正规的CA运营商应该具备的基本条件)对这些用户信息进行审查和核实，必要的时候甚至需要亲自查访用户等。CA可能对某些信息还有特殊要求，比如要求国家名字必须跟CA本身设定的一样，或者要求省份跟CA设置的一样，这些要求通常不需要人工审查，计算机程序可以比我们做得更好。OpenSSL通过设置OpenSSL配置文件(默认是opensl.cnf)的匹配策略来对这些字段提出不同的要求，这种策略通常有三种:匹配、支持和可选。匹配也就是要求申请填写的信息跟CA设置信息必须一致，支持是指必须填写这项申请信息，可选就灵活多了，可有可无。如果通过了所有这些严格的审查措施，那么CA就可以给你签发证书了，如果CA是建立在OpenSSL指令的基础上，那么其使用的签发指令可能是ca，也可能是x509，但更可能是ca指令，因为它本身就是OpenSSL的一个模拟CA。

证书验证

• 有了一个证书后你就可以在数字世界中必要的时候随时出示这个证书证明你的身份。但是拿到你证书的人当然不会看一眼就信任你的证书，它需要仔细验证你的证书，需要验证的信息包括:CA的数字签名、证书的有效期、证书是否被吊销及其他一些可能的限制选项。在证书验证过程中出现的一个问题是，这个需要验证你的证书的用户是否具备验证你的证书的能力?如果用户自己具备验证能力和验证所需要的材料，就可以自己验证，比如使用OpenSSL的verify程序完成验证过程。如果用户自己没有能力或者没有足够的资料进行验证，那么可以到CA或者CA指定的机构验证证书，在线证书服务协议(OCSP)规定了相应的规则，OpenSSL也提供了ocsp指令完成相应的功能。需要说明的是，上面的流程只是完成了对一个数字证书合法性的验证，而并没有验证声称拥有这个证书人的真实身份。要进行这样的验证，需要具体的协议细节，但不管什么协议，验证一个实体是否确实是其生成的证书对应的用户都是基于证书内容里面包含的公钥和相应的私钥的基础上的。
• 验证方式：自行验证 或者 借助CA平台进行验证

证书吊销

• 在某些情况下，比如一个公司员工离开了原来的公司，那么他所拥有的证书也应该及时被撤销，以防止该员工可能利用原有的权限获取非法的信息。证书撤销的操作从技术上来说包括两个方面:一是从CA的证书数据库中删除被吊销的证书;二是对外公布被撤销的证书信息，如序列号等，具体来说就是生成和公布证书吊销列表CRL。如果你使用的是OpenSSL的ca指令作为CA中心服务程序，那么可以使用ca指令的revoke选项和gencrl选项实现这些证书吊销的操作。

证书过期

• 证书的使用有一定的期限，这是为了确保证书安全性和有效性的需要。证书过期后，CA需要更新证书库中已经过期的证书的状态，比如对过期证书归档和将其从有效证书库中删除等操作。如果使用OpenSSL的ca指令，那么需要使用updatedb选项更新证书库中证书的标记状态

证书的封装类型

X.509证书

• X.509证书包含的内容主要是用户信息、证书序列号、签发者、有效期、公钥、其他信息及CA的数字签名，这些在公钥基础设施部分已经作了介绍。我们需要确认的是，X.509只包含了一个公钥，而没有这个公钥对应的私钥的任何信息。公钥是可以公开的，所以X.509证书一般也是随意公开的，任何人都可以获取你的X.509证书，然后使用它来跟你通信。
• 比如在SSL协议中，在服务器要跟你建立安全信道的时候，就会给你发送它自己的X.509证书，以便证明自己的身份，这是必要的，也是安全的，它不用担心你会利用它的X.509冒充它欺骗其他用户，因为你没有X.509证书里面公钥相应的私钥，达不到这样的目的。
• X.509证书适用于一般的证书应用模式。Windows平台对X.509证书是认可的，如果要在Windows平台查看和管理X.509证书，需要将X.509证书文件后缀名改成cer、der或者crt之一。OpenSSL从来不会从文件名称这些表面上的东西判断一个证书的格式，它对X.509证书的支持是基于其文件内容的，一般来说，PEM编码和DER编码都是可以被接受的。并且，OpenSSL本身的ca指令颁发的证书就是X.509标准格式的。

PKCS#12证书

• 如果你的证书是使用OpenSSL或其他产品申请的，而不是使用微软自身的KeyStore生成密钥对并在线申请的，那么要在IE或IS服务器上使用该证书，你就得想办法把证书和相应的私钥关联起来，并让微软的软件认可它们之间的关联关系。这时候你需要使用的就不仅仅是一个X.509证书，而是X.509证书和它相应的私钥。
• 还有另外一种情况。一般来说，证书相应的私钥应该保存在硬件设备中，如SmartCard和USBKey以确保其安全性，计算机存储总是让人不放心。但是很多时候由于条件限制或者安全性要求不足以让单位的决策者掏出这么一笔钱买这些设备，那么就必须把证书和其相应的私钥保存在内存中，这就对证书和私钥的存放提出了复杂的要求。你可能需要在不同的计算机上使用相同的证书，当然，也需要相应的私钥，如果把它们保存在不同的文件中，有可能因为弄错了多个证书和私钥之间的对应关系而导致没有办法使用，所以最好是把它们保存在一起。PKCS#12格式证书就是为了适应上述的这些需求产生的，它将证书和其相应的私钥封装在一起。当然，证书和私钥需要的安全性是不一样的，证书可以公开，所以不需要加密保存;而私钥的安全性非常重要，PKCS#12采用了PKCS#8的私钥封装格式对私钥进行了基于口令的加密，虽然这种安全性很值得怀疑，但是毕竟有了一些保护。如果你把证书和私钥封装成PKCS#12格式的证书，你就可以直接把它导入到微软的平台使用(比如IE)，当然，最好之前把文件后缀名改成pfx或者p12。OpenSSL的所有指令几乎都接受PKCS#12的格式，并且不计较你用什么文件名或者后缀名。同时，OpenSSL还给出了将X.509证书和其私钥转换成PKCS#12格式证书的指令pkcs12，该指令也能实现反向的功能，即将一个PKCS#12的证书转换成一个X.509证书和一个私钥。

PKCS#7证书

• 如果你使用的是一个根CA颁发的证书，验证不会有太大的问题，你只要简单把你和你的CA证书发送给验证方就可以了，并且通常来说，验证方甚至已经有了跟你相同的CA证书，验证可能轻而易举完成了。但是如果给你颁发证书的CA不是根CA情况就显得复杂得多，如图所示，你和你的验证用户可能隶属于不同的CA，但是这些不同的CA可能属于相同的根CA，那么验证就需要更多的信息，不仅仅需要你的CA证书，还需要签发你的CA证书的上级CA证书，直到上溯到根CA证书，也就是说，验证的时候，验证方会需要一个完整的证书链。所谓证书链，就是一个用户证书和一系列与其证书相关的CA证书的有序集合。所以，考虑到用户这些需求，为了使证书用户能够正确地使用自己的证书，CA在给用户颁发证书的时候，不仅仅要给用户发放用户自己的证书，还可能需要把证书链中的所有CA证书都给用户。

•  上面所说的验证过程对于一般情形来说还太理想了，事实上，一个CA或多或少会有一些由于各种原因被吊销的证书(除非刚刚建立的CA)，这些证书可能依然在有效期内，用户验证证书通常可能不使用OCSP协议(至少该协议不总是可行的)，那么为了排除这些已经被吊销的证书，就需要通知用户那些证书已经无效，这一般通过证书吊销列表(CRL)来实现。CRL是公开的，可以自由下载，但是很多时候验证方可能要求用户给它提供合法的CRL。这样一来，用户需要给验证方提供的东西就非常多了:自己的证书、证书链上所有的CA证书和CRL。这么多东西如果一个一个地发送给接收方，他可能会烦死，因为他必须一一鉴别你发送过来的是什么东西，以及考虑怎么保存这些信息。为了避免上述所有这些尴尬的情况，PKCS#7标准的证书格式出现了。PKCS#7标准很简单:可以包含多个证书和CRL。这样就可以解决上述的问题了，在验证的时候，把自己的证书、相关证书链上的CA证书和CRL封装成一个PKCS#7格式证书发送给验证方就可以了。微软对PKCS#7证书的支持依赖文件后缀名p7，OpenSSL对PKCS#7协议的支持有限，但是提供了将普通用户证书和CRL封装成PKCS#7证书的指令crl2pkcs7，同时也提供了pkcs7指令来处理PKCS#7证书的一些相关问题。表列出了上述三种证书的基本情况。事实上，还有其他一些适应不同需要的证书封装格式，但因为使用得不多，这里不再介绍。

 证书使用

• 使用数字证书的目的只有一个，在数字世界建立一个跟现实世界完全相类似的信任模型。数字证书的作用很简单，几乎就是跟现实世界的证书(比如身份证)作用一一对应的。现实世界中的身份证是怎么使用的呢?我们下面的介绍会将数字世界对应于现实世界的名字在括号中标出。首先，公安局(CA)颁发了你的身份证(数字证书)，然后你要别人确认你的身份的时候，你拿出你的身份证，对方如果相信自己具备验证身份证真伪的能力，那么他就会通过查看公安局盖章(CA签名)、你的资料信息(用户主体信息)和其他信息来确认身份证是公安局颁发的还是伪造的。当然，如果这些都通过了，他可能还拿出一份公安局公布的无效身份证的资料(CRL)对照一下，看看你的身份证号码(证书序列号)是不是已经名列其中了。如果你是一个守法的人，这样的验证可能很顺利就通过了。但是也有可能用户觉得事关重大，根本就不相信自己现有的能力和资料能够确保身份证的合法性，那么他就需要把身份证拿到公安局或者公安局指定的某个代理机构(OCSP)确认身份证的真伪，该机构显然拥有更丰富的经验和信息来确认身份证的真伪。上面介绍的两种验证模型，也是数字世界的两种验证模型，一种是需要CA或其指定机构参与的，一种是不需要CA参与的

• 对于不需要CA参与的证书应用模型，验证用户B应该具备CA证书(或证书链)、CRL这些基本的材料和验证应用程序。对于需要CA参与的证书应用模型，用户B几乎可以不拥有任何资料，它只要可以理解CA提供的在线验证协议就行了，现在通常使用的是OCSP协议。 

证书链

• 我们回头看看图，用户A和用户B的证书是不同CA签发的，分别是CA1和CA2，那么如果A发给用户B自己的证书并要求进行验证，那么B应该怎么做呢?如果B没有CA1的证书，那么B就没有办法确认用户A证书中签名的合法性，验证过程显然没有办法进行下去。同样，要验证CA1的证书，B也需要根CA的证书，以便提取其中的公钥验证其对CA1的签名。所以，为了确保B能正确验证自己的证书，A必须给B发送三个证书:自己的证书、CA1证书和根CA证书。这三个证书就构成了一个完整的证书链。

•  一般来说，证书应用程序都应该支持证书链的构造和验证，用户只要将构造证书链需要的证书提供给应用程序就可以了。比如OpenSSL的指令verify，你只需要将构建一个完整证书链需要的证书都存放在一个文件(CAfile)或者一个目录(CApath)中，并把这个相关的信息通过指令选项输入，verify指令就会自动完成整个证书链的构造和验证过程。

用户的身份认证

• 上面我们已经顺利通过一个证书的验证了，实质上，我们仅仅是对证书本身的合法性和有效性进行了验证，对于用户是否确实拥有这个证书还需要进一步确认。需要再次强调的是，仅有证书是没有多大意义的。千万不要以为自己得到了管理员的一个数字证书就可以窃喜不已，事实上它毫无用处，在实际的应用协议中，在通过对你出示的证书进行验证之后，还要验证你是否确实拥有该证书。过程很简单，提取证书中的公钥，使用该公钥加密一个随机数，然后发送给你，并要求你解密后返回该随机数。如果你确实是证书的主人，那么你拥有相应的私钥，你可以解密发送过来的信息并得到随机数，然后返回给对方证明你的身份，对方比较本地保存的随机数和你返回的随机数，如果一致，证明你能够正确解密证书上公钥加密的数据，确认你拥有证书相应的私钥。而你如果是冒充的用户，那么这时候你就束手无策了，你没有办法正确解密得到那个随机数，从而也就狼狈地暴露了你的身份。

更多的问题

• 虽然我们有了一个合法的数字证书，但证书在具体应用环境或者协议中的使用要考虑的问题还可能有许多。首先面临的就是证书格式问题，对于具体的应用程序来说，对证书的编码格式可能有不同的限制和支持，比如一个使用非微软本身密钥产生器申请的证书需要在IE中使用，首先就必须将证书和密钥封装成PKCS#12格式才能导入到微软的机制中，而OpenSSL则不存在这样的限制。
• 其次可能还有证书本身的一些扩展字段问题，有些CA中心自己扩展了一些字段，但是这些字段在别的应用程序中并不一定能得到很好的支持，这样有可能就会导致验证失败等问题，尤其是该扩展字段标记为关键扩展之后。这样的问题要是啰嗦起来，数不胜数，如果想在碰到这些问题的时候能够迅速解决，那么最主要的就是对整个密码学技术和PKI应用有一个清晰的概念和认识。

CA的建立

• 建立一个投入实际应用的CA是一个非常复杂的问题，要考虑的不仅仅是技术上的问题，更多的是管理上的规范性问题。对于管理问题，不是本书关注的话题，不作更多的讨论。这里要说的是，怎么从技术上建立一个CA服务器。前面我们介绍了证书的各个方面，都是假设CA已经存在，但是事实上，可能你并不能找到一个合适的CA，甚至，你的任务就是建立一个CA。这时候该做些什么?事实上你有很多选择。微软平台自身就附带了一个可选的CA服务器程序，该程序能够实现申请证书和发放证书等功能。
• 此外，OpenCA也是一个选择。你还可以选择一个营利性的公共CA来建立你的证书服务体系。不过无论如何，在本书我们要讨论的重点可能是OpenSSL提供的ca指令。我并非推荐大家使用OpenSSL的ca指令，但它确实有很多值得我们使用和研究的地方。首先它是开放源代码的，这非常有好处，也适应国家对网络安全产品的要求;其次它是免费获得的，任何人都可以拥有，不存在太多的版权限制;再次，其功能也还不错，通过几次的改进，其功能已经远远超出了当时作为一个演示ca程序的范畴。无论你使用哪种CA应用程序，要使一个CA服务器开始运作，首先要为CA自身生成一对密钥和一个证书。因为CA的证书安全性非常重要，所以其密钥的长度应该比普通的证书密钥长度长一些，比如采用2048位的RSA密钥。如果CA是一个根CA，那么其证书就是一个自签名证书，即使用自己的私钥对证书内容(包括自己的公钥)进行签名。
• 如果不是一个根CA，那么应该向上级CA申请证书。OpenSSL的req指令可以提供生成证书请求和自签名根证书的功能，在后面的章节中将会作详细的介绍。CA拥有了自己的证书和私钥之后，CA应用程序一般来说就可以开始运行了。

OpenSSL证书和CA指令概览