网站建设试题卷,下载网站模板,网站可以用PS设计吗,刘强东称软弱的人无法成就伟大公司为什么需要证书
实现了公钥和私钥的相互验证#xff0c;但是任何人都可以生成很多的密钥对#xff0c;密钥对并没有关联实体身份#xff0c;因此诞生可数字证书前提是CA是所有用户都信任的用户需要将自己的信息和公钥交给CA进行认证生成一个属于自己并被其与用户认可的数字…为什么需要证书
实现了公钥和私钥的相互验证但是任何人都可以生成很多的密钥对密钥对并没有关联实体身份因此诞生可数字证书前提是CA是所有用户都信任的用户需要将自己的信息和公钥交给CA进行认证生成一个属于自己并被其与用户认可的数字证书然后双方通信的时候使用与数字证书里面对应的公钥进行数字签名
证书生命周期
证书申请
证书的声明周期是指证书申请到证书被吊销整个过程这个过程中涉及到证书的申请、颁发、使用和其余各个管理方面的问题最常用的是RSA密钥和DSA密钥算法的类型和具体的使用场景相关比如用于密钥交换目的的证书就不可以使用DSA密钥只能使用RSA密钥生成密钥对可以使用OpenSSL的genrsa和gendsa命令还可以使用req指令申请的时候需要涉及到 用户需要填写哪些信息 以及如何对填写的信息进行格式化操作PKCS#10标准规定了这些相关的格式。其基本思想是用户根据要求填写这些信息然后将这些信息和用户产生的公钥一起用相应的私钥签名发给CA验证这可以使得CA确认这些信息是申请的用户自己发送的因为CA可以把证书请求中的公钥拿出来验证这个证书请求的签名。OpenSSL提供了req指令帮助我们填写和生成这个格式复杂的证书请求当然根据不同CA的要求你可能需要更改OpenSSL的配置文件(默认是openssl.cnf)中证书请求相关的部分配置。完成这些工作你就可以把证书请求交给CAOpenSSL的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证书的支持依赖文件后缀名p7OpenSSL对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指令概览
