数字证书的认证过程

证书的认证过程（也称验证过程）
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。

文章转载于网络