众所周知，公钥密码学通过使用公钥和私钥这一密钥对，使数字签名和加密通讯等密钥服务变得容易起来。公钥技术之所以能得到广泛的应用，原因就在于对那些使用密钥对中的公钥来获得安全服务的实体，他们能很方便地取得公钥，即密钥分发与管理比起对称密钥的分发与管理变得简单了。所以有人称，非对称密码算法是计算机安全通讯的一次技术革命。 当然，公钥的分发也需要数据完整性保护措施，即需要数据完整性服务来保障公钥不被篡改，并保证公钥一定要有与其声明持有者的身份相对应绑定的机制，最终目的是能提供一种简单安全识别的机制，其一可以使公钥及其相关信息的完整性得到保障；其二可以使公钥及其相关信息以一种可信的方式与其声明所有者绑定在一起。 这就是证书机制，证书在电子商务中是一种权威性的文档，证书的颁发者必须具有可信赖性，它是由权威性、可信任性和公正性的第三方机构所颁发的。证书是一种安全机制，它能保证实现和完成PKI的身份认证、完整性、保密性及不可否认性的安全服务。 证书是一种新的安全机制，一般初期使用者会感到困惑。如一个网上购物者或网上银行客户，或是一个某银行支付网关的管理员，他（她）们经常会想：为什么浏览器 /服务器中装入数字证书就会在互联网上变得安全了呢？它们在实际认证中是如何操作的？它是如何保证安全的呢？针对这些常见的问题，本文通过讨论 X.509V3版公钥证书的结构和语义、内容和用途以及对证书的哪些项要进行检查和如何进行检查的全部过程等，来说明证书认证的安全性。相信广大读者在了解了证书认证的“游戏规则”以后，对证书机制所能完成的身份识别和鉴别认证的安全服务会有所理解。证书确实是网上交易安全的守护神。 一、有关概念 1.关于CA CA(Certification Authority)在PKI中称“认证机构”，它为电子商务环境中各个实体颁发电子证书，即对实体的身份信息和相应公钥数据进行数字签名，用以捆绑该实体的公钥和身份，以证明各实体在网上身份的真实性；并负责在交易中检验和管理证书。CA是认证电子商务和网上银行交易的权威性、可信赖性及公正性的第三方机构，是电子商务的重要基础设施，是电子商务的安全保证。 2.关于数字证书 数字证书也叫电子证书,或简称证书，在很多场合下,数字证书、电子证书和证书都是X.509公钥证书的同义词，它符合ITU－T X.509 V3标准。证书是随PKI的形成而新发展起来的安全机制，它实现身份的鉴别与识别（认证）、完整性、保密性及不可否认性安全服务（安全需求）；数字证书是电子商务中各实体的网上身份的证明，它证明实体所声明的身份与其公钥的匹配关系，使得实体身份与证书上的公钥相绑定；从公钥管理的机制来讲，数字证书是公钥体制密钥管理的媒介，即在公钥体制中，公钥的分发、传送是靠证书机制来实现的。所以有时也将数字证书称为公钥证书；数字证书是一种权威性的电子文档，它是由具有权威性、可信任性及公正性的第三方机构（CA）所颁发。 二、证书的内容及用途 CFCA所发放的证书均遵循X.509 V3标准，其基本格式及其用途如下： 1.Certificate Format Version 证书版本号,用来指定证书格式用的X.509版本号，用于目录查询。 2.Certificate Serial Number 证书序列号,证书颁发者指定证书唯一序列号, 以标识CA发出的所有证书，用于目录查询。 3.Signature Algorithm Identifier 签名算法标识,用来指定本证书所用的签名算法（如SHA－1、RSA）。 4.Issuer 签发此证书的CA名称,用来指定签发证书的CA的可识别的唯一名称(DN, Distinguished Name)，用于认证。 5.Validity Period 证书有效期,指定证书起始日期（notBefore）和终止日期（notAfter），用于校验证书的有效性。 6.Subject 用户主体名称,用来指定证书用户的X.500唯一名称(DN)，用于认证。 7.Subject Public Key Information 用户主体公钥信息。 (1)Algorithm Identifier,算法标识。用来标识公钥使用的算法。 (2)Subject Public Key,用户主体公钥。用来标识公钥本身，用于加/解密和数字签名。 8.Issuer Unique ID 颁发者可选唯一标识，很少用。 9.Subject Unique ID 主体证书拥有者唯一标识，很少用。 10.Extensions 证书扩充部分(扩展域)，用来指定额外信息。 (1)Authority Key Identifier,签发者CA的公钥标识。 Key Identifier,公钥标识; Cert Issuer,证书签发者的甄别名,电子邮件、IP地址等; Cert Serial Number,签发证书的序列号,用于签发根证书及交叉认证。 (2)Subject Key Identifier,用户主体的公钥标识。证书主体所含密钥的唯一标识，用来区分一个证书拥有者的多对密钥，主要用于对由以前公钥加密过的文件进行解密。 (3)CRL Distribution Point, CRL分布。指明CRL分段的地点，用于分布式存放。 (4)Key Usage,证书中的公钥用途，用来指定公钥用途,数字签名、加密等。 (5)Private Key Usage Period,用户的私钥有效期。用来指定用户签名私钥的起始日期和终止日期。 (6)Certificate Policies,CA承认的证书政策列表。用来指定用户证书所适用的政策, 证书政策可由对象标识符表示，一个详细提示（200字符）。 (7)Policy Mappings,策略映射。表明在两个CA之间一个或多个策略标识的等价映射关系——仅在CA证书里存在。 (8)Subject Alt Name,用户的代用名。用来指定用户的代用名。 (9)Issuer Alt Name,CA的代用名。用来指定CA的代用名。 (10)Basic Constraints,基本制约。用来表明证书用户是最终用户还是CA，用于交易路径。 (11)Subject Directory Attributes,用户主体目录属性。指出证书拥有者的一系列属性。 11.Signature Acgorithm CA签名算法标识。 12.CA Signature CA签名。 三、证书的认证过程 以上介绍了证书结构、内容及用途，那么证书是如何相互认证的呢？相互的身份是如何识别的？为什么应用证书机制就是安全的呢？ 首先看一下证书的认证过程（也称验证过程）。 1.拆封证书 所谓证书的拆封，是验证发行者CA的公钥能否正确解开客户实体证书中的“发行者的数字签名”。两个证书在交换传递之后，要进行拆封，看是否能够拆封。一个证书或证书链的拆封操作，是为了从中获得一个公钥。可示为X1p?X1<<X2>>,这为一个中缀操作，其左操作数为一个认证机构的公钥，右操作数则为该认证机构所颁发的一个证书。如果能正确解开，输出结果为用户的公钥。 从证书内容列表中可以看出，证书结构的最后内容是认证机构CA的数字签名，即一个可信任的CA已经在证书上用自己的私钥做了签名。如果用该CA的公钥就可以拆封一个用户实体的证书，那么，这个签名被验证是正确的。因为它证明了这个证书是由权威的、可信任的认证机构所签发。因此，这个实体证书是真实可信的。 2.证书链的验证 所谓证书链的验证，是想通过证书链追溯到可信赖的CA的根（ROOT）。换句话说，要验证签发用户实体证书的CA是否是权威可信的CA，如CFCA。证书链验证的要求是，路径中每个证书从最终实体到根证书都是有效的，并且每个证书都要正确地对应发行该证书的权威可信任性CA。操作表达式为 Ap?A<<B>>B<<C>>,指出该操作使用A的公钥，从B的证书中获得B的公钥Bp，然后再通过 Bp来解封C的证书。操作的最终结果得到了C的公钥Cp。这就是一个证书链的认证拆封过程。 (1)证书链的定义。证书链也称认证链，它是最终实体到根证书的一系列证书组成，这个证书链的处理过程是所有根的前辈指向最开始的根证书，即子辈连向父辈。如图1所示。 证书（无论是SET或是Non－SET证书）是通过图1所显示的信任层次来验证的，每个证书都对应于发行该证书的实体的数字签名。如图所示，SET：CCA（MCA、PCA）—B—R；non－SET：CCA（BCA、UCA）—P—R。这样就可用一级一级的公钥解开每级的数字签名，一直上溯到可信任的根CA ROOT。它们是通过直到根CA ROOT的信任层次来验证证书的。 (2)从用户实体证书到ROOT CA的证书链确认，其具体的做法如下页图2所示。 从以上对比中可以看出：用户实体证书中的Authority Key Identifier扩展项Cert Issuer，即证书签发者的甄别名，应当与CA证书中签发此证书的CA名称相匹配，如图中箭头所指。即CA证书中的Subject Name是用户实体证书中Issuer Name的父名，对上级CA来说又成为子名，CA证书中Issuer Name是上一级CA的名字，成为可信任的链状结构。这样通过各级实体证书的验证，逐渐上溯到链的终止点——可信任的根CA，如CFCA。 3．序列号验证 序列号的验证是指检查实体证书中的签名实体序列号是否与签发者证书的序列号相一致，验证证书的真伪。验证操作过程是：用户实体证书中的Authority Key Identifier扩展项Cert Serial Number,即签发证书的序列号，检查CA证书中的Certificate Serial Number 证书序列号，二者应该相一致，否则证书不是可信任的认证机构CA所签发。 4．有效期验证 有效期验证就是检查用户证书使用的日期是否合法，有无过期。具体做法为： （1）用户实体证书的有效期Validity Period及私钥的有效期Priva Key Usege Period,应当在CA证书的有效日期Validity Period之内。如图2中粗箭头所示，超过CA证书有效期，实体证书应作废，交易是不安全的。 （2）用户实体证书有效期开始时间Validity Period中notBefore日期应在CA证书的私钥有效期Private Key Usagc Period日期之内，否则证书是不安全的。 5．证书作废止列表查询 所谓证书作废止列表查询，是检查用户的证书是否已经作废，并发布在证书吊销列表中。一般称CRL查询，俗称“黑名单查询”。一个实体证书因私钥泄密等原因，需要废止时，应及时向CA声明作废。CA实时地通过LDAP标准协议向证书库中以X.500的格式进行发布，以供访问时实体间进行开放式查询。 图3中所示为浏览器和Web服务器之间进行的双方认证，即进行双向CRL查询，在Web服务器查询浏览器证书是否为“黑名单”的同时，浏览器也去证书库查询Web服务器证书是否为有效。此为“双向认证”，CFCA的企业级高级证书即为这种机制，是中国金融CA PKI的特点。一般B to B模式的网上银行、网上购物皆采取这种方式。当然，也有“单向认证”方式，即Web服务器只去查验浏览器证书的有效性，如SSL证书的认证，这是一般CA 的普遍做法。 6.证书使用策略的认证 证书的使用方式与任何声明的策略Certificate Policy或使用限制相一致，即用户实体证书中的Certificate Policies应为CA所承认的证书政策列表。它是用特殊扩展域来限定的，用来指定用户证书所适用的政策，这些政策应在CA的CPS中有明确规定，对象标识符不超过200个字符。没有CA承认的政策，用户证书是不能执行的。如Policy URL、 Policy E－mail地址，必须由根政策陈述。 7.最终用户实体证书的确认 为了证书的使用安全，CA所签发的认证机构内部管理员的证书要与最终用户实体证书相区分。为此： (1)在扩展域基本制约Basic Constraints中其默认值表示最终实体（End Entity），以区别其他CA内部管理证书，防止证书用于不同的目的。 (2)在扩展域Key Usage中要对声明的用途有效，用于数字签名或用于传输加密，为确保安全，要明确分开，不能混用，以备争议时审计，为仲裁提供依据。 当然，以上这些操作对用户来说都是透明的。 关于数字证书(双向)的若干想法[ZT] 双向数字认证,需要客户端和服务器均有自己的私钥和公钥(一般为X509证书), 工程服务器为Apache或是Tomcat,客户端一般可发布为Pkcs12包. SSL工作原理: SSL协议使用不对称加密技术实现会话双方之间信息的安全传递。可以实现信息传递的保密性、完整性，并且会话双方能鉴别对方身份。不同于常用的http协议，我们在与网站建立SSL安全连接时使用https协议，即采用https://ip:port/的方式来访问。当我们与一个网站建立https连接时，我们的浏览器与Web Server之间要经过一个握手的过程来完成身份鉴定与密钥交换，从而建立安全连接。具体过程如下： 用户浏览器将其SSL版本号、加密设置参数、与session有关的数据以及其它一些必要信息发送到服务器。 服务器将其SSL版本号、加密设置参数、与session有关的数据以及其它一些必要信息发送给浏览器，同时发给浏览器的还有服务器的证书。如果配置服务器的SSL需要验证用户身份，还要发出请求要求浏览器提供用户证书。 客户端检查服务器证书，如果检查失败，提示不能建立SSL连接。如果成功，那么继续。客户端浏览器为本次会话生成pre-master secret，并将其用服务器公钥加密后发送给服务器。如果服务器要求鉴别客户身份，客户端还要再对另外一些数据签名后并将其与客户端证书一起发送给服务器。 如果服务器要求鉴别客户身份，则检查签署客户证书的CA是否可信。如果不在信任列表中，结束本次会话。如果检查通过，服务器用自己的私钥解密收到的pre-master secret，并用它通过某些算法生成本次会话的master secret。 客户端与服务器均使用此master secret生成本次会话的会话密钥(对称密钥)。在双方SSL握手结束后传递任何消息均使用此会话密钥。这样做的主要原因是对称加密比非对称加密的运算量低一个数量级以上，能够显著提高双方会话时的运算速度。 客户端通知服务器此后发送的消息都使用这个会话密钥进行加密。并通知服务器客户端已经完成本次SSL握手。 服务器通知客户端此后发送的消息都使用这个会话密钥进行加密。并通知客户端服务器已经完成本次SSL握手。 本次握手过程结束，会话已经建立。双方使用同一个会话密钥分别对发送以及接受的信息进行加、解密。 几个概念: 1.个人信息交换 (PKCS #12) 个人信息交换格式（PFX，也称为 PKCS #12）允许证书及相关私钥从一台计算机传输到另一台计算机或可移动媒体。 2.DER 编码和Base64编码 在各类证书,私钥及其参数一般有两种表示,Der为二进制表示格式,Base64不言自明,在应用过程中无甚差别,但是因为Base64的文本性,其很容易在HTTP环境传播. 3.PKCS#10：描述证书请求语法, 证书请求文件一般以csr为扩展名. 4.X509证书封装了公钥.一般意义可以认为证书就是公钥,当然公钥未必是以X509证书形式存在. 5.PKCS7,一般用于证书链.以p7b结尾. 6.CRL, Certificate revocation list.证书失效列表. 7.Openssl提供了CA认证的全面支持,Keytool及JCA,JCE API对应了Java对PKI实现 若干问题. 1.客户端数字证书及私钥的发放方法, 可以客户到柜台,由营业员办理 可以由客户生成自己的CSR文件,提交到网站,由系统自己生成. 由客户在网页上添加自己相关信息,由系统生成,发回客户. 以上三种方法都需要进行确认客户的真实性.都需要开发相应的支持系统.可用Java JCE API,Openssl API或是Openssl Commandline,Keytool实现. 2.数字证书 失效问题. 如果发生证书对应密钥丢失,客户可能需要对证书进行调销,这需要建立建立比较完善的CA基础,支持Certificate revocation list,这需要完整的CA解决方案.需要开发相应支持系统. 3.是否所有的客户都必须选用数字证书. 理论上,至少在一段时间的转移过程内,会出现使用和不使用数字证书的客户同时存在,这样需要建立两套不同的系统.还要解决同一入口问题. 4.程序是否还需要用户名和密码的认证. 5.是否支持使用USB Key(这个应该不需要额外的开发工作). 6.项目前台使用Flash管理对后台服务器的连接,经测试能够读取所驻留浏览器的证书(及私钥)信息,成功建立双向SSL连接. 7.纯从安全角度讲,使用由verisign或其它可信的CA机关认证的证书并没有好处,但这样能提高客户对公司的信任度,使公司能明确的向客户确认自己的身份, 从实现角度讲,如果采用自签名CA的话,只是由公司内部CA对客户证书进行签名, 如果是使用经过如verisign签名的证书,那么公司将是二级CA,即证书的信任需要一个证书链,同样也是由公司内的二级CA对客户证书进行签发. 8.调查实现的步骤, 因为没有正式的证书及密钥,测试过程选用了自签名的证书,另外也没有使用完整的CA基础,没有考虑CRL的问题,即证书注销问题.