数字证书详解.doc

数字证书一. 什么是数字证书？ 数字证书就是网络通讯中标志通讯各方身份信息的一系列数据，其作用类似于现实生活中的身份证。它是由一个权威机构发行的，人们可以在互联网上用它来识别对方的身份。 最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。一般情况下证书中还包括密钥的有效时间，发证机关(证书授权中心)的名称，该证书的序列号等信息，证书的格式遵循ITUT X.509国际标准。 一个标准的X.509数字证书包含以下一些内容： 证书的版本信息； 证书的序列号，每个证书都有一个唯一的证书序列号； 证书所使用的签名算法； 证书的发行机构名称，命名规则一般采用X.500格式； 证书的有效期，现在通用的证书一般采用UTC时间格式，它的计时范围为1950-2049； 证书所有人的名称，命名规则一般采用X.500格式； 证书所有人的公开密钥； 证书发行者对证书的签名。 使用数字证书，通过运用对称和非对称密码体制等密码技术建立起一套严密的身份认证系统，从而保证：信息除发送方和接收方外不被其它人窃取；信息在传输过程中不被篡改；发送方能够通过数字证书来确认接收方的身份；发送方对于自己的信息不能抵赖。 二. 为什么要使用数字证书？ 基于Internet网的电子商务系统技术使在网上购物的顾客能够极其方便轻松地获 得商家和企业的信息，但同时也增加了对某些敏感或有价值的数据被滥用的风险。买 方和卖方都必须对于在因特网上进行的一切金融交易运作都是真实可靠的，并且要使 顾客、商家和企业等交易各方都具有绝对的信心，因而因特网(Internet)电子商务 系统必须保证具有十分可靠的安全保密技术，也就是说，必须保证网络安全的四大要 素，即信息传输的保密性、数据交换的完整性、发送信息的不可否认性、交易者身份的确定性。1、信息的保密性交易中的商务信息均有保密的要求。如信用卡账号和用户名被人知悉，就可能 被盗用，订货和付款的信息被竞争对手获悉，就可能丧失商机。因此在电子商务的信息传播中一般均有加密的要求。2、交易者身份的确定性网上交易的双方很可能素昧平生，相隔千里。要使交易成功首先要能确认对方的 身份，对商家要考虑客户端不能是骗子，而客户也会担心网上的商店不是一个玩弄欺 诈的黑店。因此能方便而可靠地确认对方身份是交易的前提。对于为顾客或用户开展 服务的银行、信用卡公司和销售商店，为了做到安全、保密、可靠地开展服务活动， 都要进行身份认证的工作。对有关的销售商店来说，他们对顾客所用的信用卡的号码 是不知道的，商店只能把信用卡的确认工作完全交给银行来完成。银行和信用卡公司 可以采用各种保密与识别方法，确认顾客的身份是否合法，同时还要防止发生拒付款 问题以及确认订货和订货收据信息等。3、不可否认性由于商情的千变万化，交易一旦达成是不能被否认的。否则必然会损害一方的利 益。例如订购黄金，订货时金价较低，但收到订单后，金价上涨了，如收单方能否认 受到订单的实际时间，甚至否认收到订单的事实，则订货方就会蒙受损失。因此电子 交易通信过程的各个环节都必须是不可否认的。4、不可修改性交易的文件是不可被修改的，如上例所举的订购黄金。供货单位在收到订单后， 发现金价大幅上涨了，如其能改动文件内容，将订购数1吨改为1克，则可大幅受益， 那么订货单位可能就会因此而蒙受损失。因此电子交易文件也要能做到不可修改，以 保障交易的严肃和公正。人们在感叹电子商务的巨大潜力的同时，不得不冷静地思考，在人与人互不见面 的计算机互联网上进行交易和作业时，怎么才能保证交易的公正性和安全性，保证交易双方身份的真实性。国际上已经有比较成熟的安全解决方案， 那就是建立安全证书体系结构。数字安全证书提供了一种在网上验证身份的方式。安全证书体制主要采 用了公开密钥体制，其它还包括对称密钥加密、数字签名、数字信封等技术。我们可以使用数字证书，通过运用对称和非对称密码体制等密码技术建立起一套严密的身份认证系统，从而保证：信息除发送方和接收方外不被其它人窃取；信息在传输过程中不被篡改；发送方能够通过数字证书来确认接收方的身份；发送方对于自己的信息不能抵赖。三.数字证书原理？1.密码学在密码学中，有一个五元组：明文、密文、密钥、加密算法、解密算法，对应的加密方案称为密码体制（或密码）。明文：是作为加密输入的原始信息，即消息的原始形式所有可能明文的有限集称为明文空间。密文：是明文经加密变换后的结果，即消息被加密处理后的形式，所有可能密文的有限集称为密文空间。密钥：是参与密码变换的参数，一切可能的密钥构成的有限集称为密钥空间。加密算法：是将明文变换为密文的变换函数，相应的变换过程称为加密，即编码的过程。解密算法：是将密文恢复为明文的变换函数，相应的变换过程称为解密，即解码的过程。现代密码学算法：对称算法： 加密和解密使用同一密钥 主要算法包括：DES、3DES、RC2、RC4 加/解密速度快，但密钥分发问题严重非对称算法： 不需要首先共享秘密 两个密钥同时产生 ：一把密钥（公钥）是公开的，任何人都可 以得到。另一把密钥（私人密钥）只有密钥的拥有者知道。 用其中一把密钥（公钥或者是私钥）加密的信息，只能用另一把 打开。 RSA算法，ECC（椭圆曲线）算法 由已知的公钥几乎不可能推导出私钥 强度依赖于密钥的长度 很慢-不适合加密大数据 公钥可以广泛地、开放地分发 用于加密，签名/校验，密钥交换 主要算法包括：RSA，ECC，Diffie-Hellman， DSA数字摘要： 把可变输入长度串转换成固定长度输出串的一种函数。称输出串 为输入串的指纹，或者数字摘要； 不同明文的摘要相同的概要是非常非常小的；而同样明文其摘要必定一致； 明文的长度不固定，摘要的长度固定。 没有密钥 不可回溯 典型算法：MD5, SHA-1 用于完整性检测，产生数字签名最好的解决方案： 使用对称算法加密大的数据 每次加密先产生新的随机密钥 使用非对称算法交换随机产生的密钥 用非对称算法做数字签名（对散列值即摘要做数字签名） 四条基本规则 先签名，然后加密 加密之前先压缩 用你自己的私钥做签名 用接收者的公钥做加密加密：解密：怎样解决4个通讯安全需求？ 私密性加密 完整性？ 不可否认性？ 身份认证 ？问题：如何解决以上三个问题？2.数字签名数字签名采用公钥体制（PKI），即利用一对互相匹配的密钥进行加密、解密。每个用户自己设定一把特定的仅为本人所知的私有密钥(私钥)，用它进行解密和签名；同时设定一把公共密钥(公钥)并由本人公开，为一组用户所共享，用于加密和验证签名。当发送一份保密文件时，发送方使用接收方的公钥对数据加密，而接收方则使用自己的私钥解密，这样信息就可以安全无误地到达目的地了。通过这种手段保证加密过程是一个不可逆过程，即只有用私有密钥才能解密。在公开密钥密码体制中，常用的一种是RSA体制。其数学原理是将一个大数分解成两个质数的乘积，加密和解密用的是两个不同的密钥。即使已知明文、密文和加密密钥(公开密钥)，想要推导出解密密钥(私密密钥)，在计算上是不可能的。按现在的计算机技术水平，要破解目前采用的1024位RSA密钥，需要上千年的计算时间。公开密钥技术解决了密钥发布的管理问题，商户可以公开其公开密钥，而保留其私有密钥。购物者可以用人人皆知的公开密钥对发送的信息进行加密，安全地传送给商户，然后由商户用自己的私有密钥进行解密。用户也可以采用自己的私钥对信息加以处理，由于密钥仅为本人所有，这样就产生了别人无法生成的文件，也就形成了数字签名。采用数字签名，能够确认以下两点：(1)保证信息是由签名者自己签名发送的，签名者不能否认或难以否认；(2)保证信息自签发后到收到为止未曾作过任何修改，签发的文件是真实文件。数字签名具体做法是：(1)将报文按双方约定的HASH算法计算得到一个固定位数的报文摘要。在数学上保证：只要改动报文中任何一位，重新计算出的报文摘要值就会与原先的值不相符。这样就保证了报文的不可更改性。(2)将该报文摘要值用发送者的私人密钥加密，然后连同原报文一起发送给接收者，而产生的报文即称数字签名。这样就保证了签发者不可否认性。(3)接收方收到数字签名后，用同样的HASH算法对报文计算摘要值，然后与用发送者的公开密钥进行解密解开的报文摘要值相比较。如相等则说明报文确实来自所称的发送者。四. 数字证书是如何生成的？数字证书是数字证书在一个身份和该身份的持有者所拥有的公/私钥对之间建立了一种联系，由认证中心（CA）或者认证中心的下级认证中心颁发的。根证书是认证中心与用户建立信任关系的基础。在用户使用数字证书之前必须首先下载和安装。 认证中心是一家能向用户签发数字证书以确认用户身份的管理机构。为了防止数字凭证的伪造，认证中心的公共密钥必须是可靠的，认证中心必须公布其公共密钥或由更高级别的认证中心提供一个电子凭证来证明其公共密钥的有效性，后一种方法导致了多级别认证中心的出现。 数字证书颁发过程如下：用户产生了自己的密钥对，并将公共密钥及部分个人身份信息(称作P10请求)传送给一家认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内附了用户和他的密钥等信息，同时还附有对认证中心公共密钥加以确认的数字证书。当用户想证明其公开密钥的合法性时，就可以提供这一数字证书。证书的产生：认证中心把用户证书的基本信息做哈希算法，然后用自己的私钥对哈希值进行加密。五.数字证书是如何分发的？CA将证书分发给用户的途径有多种。第一种途径是带外分发(Out-of-band Distribution)，即离线方式。例如，密钥对是由软件运营商代替客户生成，证书也是由运营商代替客户从CA下载，然后把私钥和下载的证书一起储存在软盘里，再交给用户的。这样做的好处是免去了用户上网下载证书的麻烦。第二种途径是带内分发(In-band distribution)，即用户从网上下载数字证书到自己的电脑中。下载时，用户要向CA出示“参考号”和“授权码”，以向CA证明自己的身份。这样做成本较低，但对使用计算机不太熟悉的用户来说，可能在下载时会碰到一些麻烦。除了以上两种方式外，CA还把证书集中放置在公共的数据库中公布，用户可以随用随查询随调用。六.数字证书是如何存储的？数字证书和私钥储存的介质有多种，大致分为硬证书和软证书。可以存储在计算机硬盘、软盘、智能卡或USB key里。1、关于私钥的唯一性严格地讲，私钥既然是世上唯一且只由主体本身持有，它就必须由主体的计算机程序来生成。因为如果在别处生成将会有被拷贝的机会。然而在实际应用上并非如此，出于某些特殊需要(例如，如果只有一份私钥，单位的加密文件就会因为离职员工带走 私钥而无法解密。)加密用的公/私钥对会要求在可信的第三方储存其备份。这样，加密用的私钥可能并不唯一。然而签名用的私钥则必须保持唯一，否则就无法保证被签名信息的不可否认性。在生成用户的密钥对时，用于加密的公/私钥对可以由CA、RA产生，也可以在用户终端的机器上用专用的程序(如浏览器程序或认证软件)来产生。用于数字签名的密钥对原则上只能由用户终端的程序自行产生，才能保证私钥信息的私密性以及通信信息的不可否认性。有人可能会产生疑问：有的加密和签名的密钥对都是由软件运营商代替客户生成的，这是否破坏了上述的私钥唯一性原则呢？答案是否定的。这时候，私钥的唯一性要依靠法律合同的保证以及操作过程中相应制度的约束，使得不可否认性得到支持。出于这种机制，我们仍然可以认为，用户的签名私钥是唯一的。2、证书，私钥，到底保护哪一个？我们常常听到有人说：“保管好你的软盘，保管好你的KEY，不要让别人盗用你的证书。”有些教科书上也这样讲。应该说，这句话是有毛病的。数字证书可以在网上公开，并不怕别人盗用和篡改。因为证书的盗用者在没有掌握相应的私钥的情况下，盗用别人的证书既不能完成加密通信，又不能实现数字签名，没有任何实际用处。而且，由于有CA对证书内容进行了数字签名，在网上公开的证书也不怕黑客篡改。我们说，更该得到保护的是储存在介质中的私钥。如果黑客同时盗走了证书和私钥，危险就会降临。3、为什么说USB key安全性好？不同的存储介质，安全性是不同的。如果证书和私钥储存在计算机的硬盘里，计算机一旦受到黑客攻击，(例如被埋置了木马程序)证书和私钥就可能被盗用。使用软盘或存储型IC卡来保存证书和私钥，安全性要比硬盘好一些，因为这两种介质仅仅在使用时才与电脑相连，用完后即被拔下，证书和私钥被窃取的可能性有所降低。但是黑客还是有机会，由于软盘和存储型IC卡不具备计算能力，在进行加密运算时，用户的私钥必须被调出软盘或IC卡进入外部的电脑，在这个过程中就会造成一定的安全隐患。使用智能卡(含CPU的IC卡)储存数字证书和私钥是更为安全的方式。为什么这样说呢？原来智能卡具有一定的计算机的功能，芯片中的CPU就是一台小小的计算机。产生公私密钥对的程序(指令集)是智能卡生产者烧制在芯片中的ROM中的，密码算法程序也是烧制在ROM中。公私密钥对在智能卡中生成后，公钥可以导出到卡外，而私钥则存储于芯片中的密钥区，不允许外部访问。智能卡中密钥文件存储在E2PROM之中。对密钥文件的读写和修改都必须由卡内的程序调用。从卡接口的外面，没有任何一条命令能够对密钥区的内容进行读出、修改、更新和删除、。除非设计和编写卡操作系统(COS)的人自己在COS上留了后门，只有他才知道如何从外部调出密钥区的内容。但我们可以排除黑客与COS设计者相勾结的这种几率极小的可能性。在加密和签名的运算过程中，外部计算机中的应用软件使用智能卡API调用的方式，输入参数、数据和命令，启动智能卡内部的数字签名运算、密码运算等，并获得返回结果。由于智能卡内部的CPU可以完成这些操作，全过程中私钥可以不出智能卡介质，黑客的攻击程序没有机会去截获私钥，因此这就比证书和私钥放在软盘或硬盘上要安全得多。从物理上讲，对智能卡芯片中的内容作整体拷贝也是几乎不可能的。虽然听说有人能够从智能卡芯片在操作过程中发生的微弱的电磁场变化，或者I/O口上反映出的微弱的电平变化中分析出芯片中的代码。但现在国际上对智能卡生产商的技术要求很高，要求上述的指标要低到不能够被测出来。国际上生产智能卡的公司都采用了种种安全措施，确保智能卡内部的数据不能用物理方法从外部拷贝。为了防止USBkey不慎丢失而可能被他人盗用，不少证书应用系统在使用过程中还设置了口令认证机制。如口令输入得不对，即使掌握了USB key，也不能登录进入应用系统。这种双因素认证机制可以使USB key更加安全可靠，值得提倡。USB Key和智能卡除了I/O物理接口不一样以外，内部结构和技术是完全一样的，其安全性也一样。只不过智能卡需要通过读卡器接到电脑的串行接口上，而USB Key通过电脑的通用串行总线(USB)接口直接与电脑相接。另外，USB接口的通信速度要远远高于串行接口的通信速度。现在出品的电脑已经把USB接口作为标准配置，而使用智能卡则需要加配读卡器。出于以上原因，各家CA都把USB Key作为首选的证书和私钥存储介质而加以推广。4、第二代USB Key第二代USBKey带有液晶显示屏和安全按键，按上下键可在显示屏上查看转账信息（包括收款账号、收款人姓名和交易金额等），如发现转账内容不正确，按清除键可以清楚所有输入的内容，再重新输入。当输入无误，需要使用USBKey进行签名时，在有效时限内按下物理按键后签名才能成功，否则签名操作失败，即使USBKey的密码被人截取，木马程序发起一个非法的交易申请，由于无法进行物理上的按键操作致使整个交易不能进行下去。可保证交易的内容不会被黑客程序非法修改，有效防止交易伪造和交易劫持的攻击。5、仍需注意的问题这里需要指出的是，有些号称智能卡的产品实际上只是不含CPU的存储型IC卡，它仅仅具有存储功能。上文已经介绍过，存储型IC卡的安全性与软盘相仿，对于这两种不同类型的IC卡，用户需要甄别清楚。第二个问题是，尽管智能卡在设计和生产过程中，对安全机制给以了充分的考虑和保证，然而，由于人为因素，也可能带来安全隐患。例如智能卡上提供一个闪存(flash)随机存储区域，是供写入一般用户数据或增加卡片功能的程序之用的。敏感的数据和程序不允许写在闪存区，必须写在安全存储区。制作智能卡时，安全区要通过硬件方法做掩模处理。硬件的掩模处理费工费时成本高，一般需要时间较长。有些卡商为了降低成本缩短工期迎合客户要求，将应该放在安全区中的敏感数据和程序放在闪存区中，闪存区里的内容是可以从卡片外部进行读写的，这就造成了可能被黑客侵入的安全隐患。这就要求我们对合作的IC卡厂商的工艺流程也要仔细审查。七.如何验证数字证书？以Alice验证Bob证书为例：校验Bob的证书的合法性 （1）Alice获得Bob的证书和签发Bob证书的CA的证书（2）用CA的公钥解密Bob的证书摘要（3）计算Bob的证书的摘要（4）比较这两个摘要（5）校验Bob的证书证书有效期（6）校验签发者签名（证书链）（7）检查证书作废列表（CRL,OCSP）八.CRL和OCSP是什么？证书的有效性取决于两个方面因素：第一个因素是证书有效期：证书的有效期在证书被颁发之日就已经确定了，例如CFCA(中国金融认证中心)规定个人证书的有效期是一年（可扩展），企业证书的有效期是三年。证书的有效期（Validity Period）作为一项内容被写进了数字证书之中，它用两个日期证书开始生效的日期和证书失效的日期来表示。显然，已经过了有效期的证书不能通过验证。证书有效期的设定是出于安全的考虑，当一张证书有效期将结束时，如果想继续使用就需要更新，证书更新时将产生新的公私密钥对，密钥定期更新对于证书的安全性是有好处的。第二个因素是证书注销：虽然证书有效期没有过，但是如果发生了特殊情况，例如用户发现证书遗失或私钥失密，用户会向CA/RA提出注销证书的申请，CA/RA经过审核后将实施证书注销。那么，被注销的证书也不能通过验证。第一种情况比较简单，证书的有效期就写在了证书之中，安全认证应用软件只要调出证书的内容，判断一下就知道这张数字证书当前是否还在有效期内。第二种情况则比较复杂，证书一旦发出，是不可能收回的。怎么办呢？只能申请注销。所谓注销，就是要求当初颁发这张证书的单位（CA）出一张告示，宣布某张证书已经被注销作废，警告有关的交易者注意，不要再使用与这张证书绑定的公钥。在PKI安全认证体系中，这种“告示”称为证书注销列表（或证书撤销清单、证书注销清单、证书废止列表等），英文原文是Certificate Revocation List，缩写为CRL。对于第二种情况，安全认证应用软件在验证证书的有效性时就需要去访问证书注销列表（CRL）。这个列表相当于“黑名单”，一旦发现通信对方的证书在这张列表中，就不能通过验证。证书注销机制可以防止证书遗失或发现私钥失密后，不法分子冒用用户证书、私钥实行欺诈交易所带来的损失。这和信用卡注销、有效证件注销的机制十分类似。注销证书的其他原因还包括：银行方面认为证书用户信用丧失、用户身份姓名发生改变、用户从他所属单位离职、岗位和职权发生变更等情况。CRL的内容根据X.509标准，CRL的内容和数据结构定义如所示： 版本 签名算法 签发者 更新时间 下一次更新时间 废止的证书列表 用户证书序列号 废止时间 CRL入口扩展CRL的内容包括CRL的版本号、计算本CRL的数字签名所用的算法的标识符（如加密算法RSA、数字摘要算法MD5等算法的标识符）、颁发CRL的CA的可识别名（DN）、CRL的发布/更新时间、被注销证书的列表（仅列出被注销证书的唯一序列号）以及扩展项。 扩展项中的内容有：（1）理由代码指出该证书被注销的理由，如：密钥损坏、CA损坏、关系变动、操作终止等；（2）证书颁发者列出该证书颁发者的名字；（3）控制指示代码用于证书的临时冻结；（4）失效日期列出该证书不再有效的日期。 为了保证CRL的真实性和完整性，CRL数据的后面附有颁发CRL的CA对CRL的数字签名。CRL的发布 CRL的数据形成后，要把它公布在网上，放在哪里呢？首先，在CFCA的证书系统中，设置了一个LDAP服务器，它与互联网相连接，有特定的IP地址，CRL的数据就放在这里供用户查询。LDAP的全称是Lightweight Directory Access Protocol，即轻型目录访问协议。LDAP的信息模型是建立在“条目”（entries）的基础上，目录的基本信息单元是条目。目录条目呈现为一个层次状的树形结构。CRL的数据以条目的形式存放在LDAP服务器中。根据LDAP目录服务所具有的特性，用户可以在网上方便快捷地对CRL进行查询。然而，CRL的数据集中存放在CA的服务器中可能带来另一个问题，就是当用户数量庞大，而且到了交易集中发生的高峰时期时，对LDAP服务器的并发访问可能造成网络和服务器的拥塞，致使交易效率急剧下降甚至超时。解决这个问题有以下两个办法：第一个办法是使用分段的CRL，就是把庞大的CRL分成很多可控的片段，并允许一个CA的证书注销信息通过多个CRL发布出来。在证书的扩展项中，有一个子项称为CRL分布点，它指出CRL分布点的分布位置，用户可以根据这个参数来访问相应的CRL。第二个办法是建立远程的镜像LDAP服务器。这些镜像服务器分布在其他城市或一些大客户的所在地。CA的LDAP主服务器负责对这些镜像服务器进行定期数据更新，以便使镜像服务器的数据内容和主服务器保持一致。设置镜像服务器的目的有两个：一是加快当地用户访问目录服务器的响应时间。二是通过设置镜像服务器可以对大量的并发访问进行分流，减轻高峰时间LDAP主服务器的负担。此外，作为一种备份机制，镜像服务器还可以在主服务器故障期间起到备份作用，提供不间断服务，这就提高了整个系统的可用率。CRL的更新从安全的角度上讲，CRL最好是进行实时更新，即一旦发生证书注销事件就立即更新，以杜绝欺诈案件的得逞。但这种实时更新的代价非常高，要占用大量的网络资源和服务器资源，反过来又会影响到网上交易的进行。因此，业内普遍的做法是定期更新，如CFCA的管理策略是对主服务器的CRL和所有远程镜像CRL每天更新一次。然而，当CRL数据总量非常庞大时，即使是每天更新一次也会给系统带来过大的负担。因此，又出现了增量CRL的概念。增量CRL的想法就是不需要每注销一张证书就产生一个完整的、越来越大的CRL，它只是产生一个与注销该证书相关的增加信息。根据定义，增量CRL是以已经颁发的注销信息为基础的，这个已经颁发的注销信息称为基本CRL，增量CRL中含有的是基本CRL中不含有的信息。引入增量CRL概念的好处是体积很小的增量CRL可以比基本CRL的更新频率高得多。例如，庞大的基本CRL的更新周期如果是一周的话，增量CRL的更新周期可以定为8小时，甚至更短。显然，这样的安全策略具有较高的安全性，而且不会给系统造成大的负担。在线查询机制OCSP 我们在上文已经提到，CRL方法存在一些缺点，其一就是CRL不可能实时更新，由于CA每隔一定时间才发布CRL，所以CRL不能及时地反应证书的状态，在安全性上有一定局限；其二，即使定期更新CRL也有麻烦，当注销证书的数量很大及用户基础很大时，CRL常常会越变越大。 每次CRL分发会大量消耗网络带宽和服务器处理能力。对于很多集群客户来说（例如一家银行和它的众多客户或者一家大企业和它的子公司、分销店），为了提高证书有效性验证效率，往往把CRL先下载到自己的服务器上，以减少对CRL的在线查询。然而频繁地下载CRL也是令用户头疼的问题。有时候，这种CRL处理方式还要求用户配置客户PC来处理来自多个证书机构的CRL。于是，另一种证书有效性的管理和查询方法，即在线查询机制应运而生。它使用的协议称为在线证书状态协议，英文是OCSP（Online Certificate Status Protocol）。在线证书状态协议（OCSP）是IETF颁布的用于检查数字证书在某一交易时间是否有效的标准，在RFC 2560中有描述。它为网上业务提供了一种检验数字证书有效性的途径，比下载和处理证书注销列表（CRL）的传统方式更快、更方便和更具独立性。OCSP实时在线地向用户提供证书状态，其结果是它比CRL处理快得多，并避免了令人头痛的逻辑问题和处理开销。OCSP在线查询机制的简单过程如下（见插图）：用户的客户机形成查询指定证书状态请求，并将请求转发到一个OCSP应答器(服务器)，应答器建立与CA证书库的连接，并查询CA证书库而获得该证书的状态，应答器返回客户机有关证书有效性信息。 简单地说，一个OCSP请求，由协议版本号、服务请求类型及一个或多个证书标识符等信息所组成；响应信息是由证书标识符、证书状态“有效”、“注销”或“未知”三个中的一个、以及验证相应时间等信息所组成。详细信息见下表所示。表：OCSP响应信息 用户的客户机形成查询指定证书状态请求，并将请求转发到一个OCSP应答器(服务器)，应答器建立与CA证书库的连接，并查询CA证书库而获得该证书的状态，应答器返回客户机有关证书有效性信息。 简单地说，一个OCSP请求，由协议版本号、服务请求类型及一个或多个证书标识符等信息所组成；响应信息是由证书标识符、证书状态“有效”、“注销”或“未知”三个中的一个、以及验证相应时间等信息所组成。详细信息见下表所示。响应信息必须经过数字签名，以保证这个信息的真实性和完整性（未被篡改）。签名密钥属于CA，即颁发这张证书的权威、可信的第三方机构，因此，在任何情况下，用户都能够信任这个信息。OCSP在线查询机制只能检测证书的注销状态，没有其他功能，例如不能检查证书的有效期，也不返回用户一个完全的证书。但是这种用法在某些应用场合下，对于验证证书的有效性来说是快速有效的。由于使用OCSP在线查询必须保持用户在线状态，且用户访问的对象集中在CA的OCSP服务器上，这同样会带来高峰负载过重，交通拥塞效率下降的问题。从以上的描述中我们可以看到，CRL和OCSP两种机制所针对的目标和实现的功能是一样的，只不过实现的方法途径不一样，两者具有异曲同工之妙。用户可根据自己的需求决定使用哪种方法，目前，CFCA对这两种方法都提供服务。九.常见的数字证书格式1.在Security编程中，有几种典型的密码交换信息文件格式：DER-encoded certificate： .cer, .crt PEM-encoded message： .pem PKCS#12 Personal Information Exchange： .pfx, .p12 PKCS#10 Certification Request： .p10 PKCS#7 cert request response： .p7r PKCS#7 binary message： .p7b .cer/.crt是用于存放证书，它是2进制形式存放的，不含私钥。 .pem跟crt/cer的区别是它以Ascii来表示。 pfx/p12用于存放个人证书/私钥，他通常包含保护密码，2进制方式 p10是证书请求 p7r是CA对证书请求的回复，只用于导入 p7b以树状展示证书链(certificate chain)，同时也支持单个证书，不含私钥。2.数字证书文件格式（cer和pfx）的区别作为文件形式存在的证书一般有这几种格式： 1.带有私钥的证书 由Public Key Cryptography Standards #12，PKCS#12标准定义，包含了公钥和私钥的二进制格式的证书形式，以pfx作为证书文件后缀名。 2.二进制编码的证书 证书中没有私钥，DER 编码二进制格式的证书文件，以cer作为证书文件后缀名。 3.Base64编码的证书 证书中没有私钥，BASE64 编码格式的证书文件，也是以cer作为证书文件后缀名。由定义可以看出，只有pfx格式的数字证书是包含有私钥的，cer格式的数字证书里面只有公钥没有私钥。在pfx证书的导入过程中有一项是“标志此密钥是可导出的。这将您在稍候备份或传输密钥”。一般是不选中的，如果选中，别人就有机会备份你的密钥了。如果是不选中，其实密钥也导入了，只是不能再次被导出。这就保证了密钥的安全。如果导入过程中没有选中这一项，做证书备份时“导出私钥”这一项是灰色的，不能选。只能导出cer格式的公钥。如果导入时选中该项，则在导出时“导出私钥”这一项就是可选的。如果要导出私钥（pfx),是需要输入密码的，这个密码就是对私钥再次加密，这样就保证了私钥的安全，别人即使拿到了你的证书备份（pfx),不知道加密私钥的密码，也是无法导入证书的。相反，如果只是导入导出cer格式的证书，是不会提示你输入密码的。因为公钥一般来说是对外公开的，不用加密3.X.509定义了两种证书：公钥证书和属性证书 PKCS#7和PKCS#12使用的都是公钥证书 PKCS7的SignedData的一种退化形式可以分发公钥证书和CRL 一个SignedData可以包含多张公钥证书 PKCS12可以包含公钥证书及其私钥，也可包含整个证书链 十.数字证书命名C（county） 国家O（organization）颁发机构名称OU(Organizational Unit) 组织单位名称CN (common name) 持有者的名称例如：CN=zhangsan，OU=beijingICBCbank，O=ICBCbank十一.证书工具使用1.KeyTool工具Java自带的keytool工具是个密钥和证书管理工具。它使用户能够管理自己的公钥/私钥对及相关证书，用于（通过数字签名）自我认证（用户向别的用户/服务认证自己）或数据完整性以及认证服务。它还允许用户储存他们的通信对等者的公钥（以证书形式）。keytool 将密钥和证书储存在一个所谓的密钥仓库（keystore）中。缺省的密钥仓库实现将密钥仓库实现为一个文件。它用口令来保护私钥。Java KeyStore的类型 JKS和JCEKS是Java密钥库(KeyStore)的两种比较常见类型(我所知道的共有5种，JKS, JCEKS, PKCS12, BKS，UBER)。JKS的Provider是SUN，在每个版本的JDK中都有，JCEKS的Provider是SUNJCE，1.4后我们都能够直接使用它。JCEKS在安全级别上要比JKS强，使用的Provider是JCEKS(推荐)，尤其在保护KeyStore中的私钥上（使用TripleDes）。 PKCS#12是公钥加密标准，它规定了可包含所有私钥、公钥和证书。其以二进制格式存储，也称为 PFX 文件，在windows中可以直接导入到密钥区，注意，PKCS#12的密钥库保护密码同时也用于保护Key。 BKS 来自BouncyCastle Provider，它使用的也是TripleDES来保护密钥库中的Key，它能够防止证书库被不小心修改（Keystore的keyentry改掉1个 bit都会产生错误），BKS能够跟JKS互操作，读者可以用Keytool去TryTry。UBER比较特别，当密码是通过命令行提供的时候，它只能跟keytool交互。整个keystore是通过PBE/SHA1/Twofish加密，因此keystore能够防止被误改、察看以及校验。以前，Sun JDK(提供者为SUN)允许你在不提供密码的情况下直接加载一个Keystore，类似cacerts，UBER不允许这种情况。 证书导入 Der/Cer证书导入： 要从某个文件中导入某个证书，使用keytool工具的-import命令： keytool -import -file mycert.der -keystore mykeystore.jks 如果在 -keystore 选项中指定了一个并不存在的密钥仓库，则该密钥仓库将被创建。如果不指定 -keystore 选项，则缺省密钥仓库将是宿主目录中名为 .keystore 的文件。如果该文件并不存在，则它将被创建。创建密钥仓库时会要求输入访问口令，以后需要使用此口令来访问。可使用-list命令来查看密钥仓库里的内容： keytool -list -rfc -keystore mykeystore.jks P12格式证书导入： keytool无法直接导入PKCS12文件。 第一种方法是使用IE将pfx证书导入，再导出为cert格式文件。使用上面介绍的方法将其导入到密钥仓库中。这样的话仓库里面只包含了证书信息，没有私钥内容。 第二种方法是将pfx文件导入到IE浏览器中，再导出为pfx文件。 新生成的pfx不能被导入到keystore中，报错：keytool错误： java.lang.Exception： 所输入的不是一个 X.509 认证。新生成的pfx文件可以被当作keystore使用。但会报个错误as unknown attr.4.1.311.17.1,查了下资料,说IE导出的就会这样,使用Netscape就不会有这个错误. 第三种方法是将pfx文件当作一个keystore使用。但是通过微软的证书管理控制台生成的pfx文件不能直接使用。keytool不认此格式，报keytool错误： java.io.IOException： failed to decrypt safe contents entry。需要通过OpenSSL转换一下： 1）openssl pkcs12 -in mycerts.pfx -out mycerts.pem 2）openssl pkcs12 -export -in mycerts.pem -out mykeystore.p12 通过keytool的-list命令可检查下密钥仓库中的内容： keytool -rfc -list -keystore mykeystore.p12 -storetype pkcs12 这里需要指明仓库类型为pkcs12，因为缺省的类型为jks。这样此密钥仓库就即包含证书信息也包含私钥信息。 P7B格式证书导入： keytool无法直接导入p7b文件。 需要将证书链RootServer.p7b（包含根证书）导出为根rootca.cer和子rootcaserver.cer 。 将这两个证书导入到可信任的密钥仓库中。 keytool -import -alias rootca -trustcacerts -file rootca.cer -keystore testkeytrust.jks 遇到是否信任该证书提示时，输入y keytool -import -alias rootcaserver -trustcacerts -file rootcaserver.cer -keystore testkeytrust.jks 总结： 1)P12格式的证书是不能使用keytool工具导入到keystore中的 2)The Suns PKCS12 Keystore对从IE和其他的windows程序生成的pfx格式的证书支持不太好. 3)P7B证书链不能直接导入到keystore，需要将里面的证书导出成cer格式，再分别导入到keystore。 2.OPENSSL使用生成私钥 Generate the private key 请使用以下命令来生成私钥 openssl genrsa des3 out .key/url 1024 如上所示，此命令将生成1024位的RSA私钥，私钥文件名为： urlwww.mydomain.co