https数字证书验证原理

数字证书是Https实现安全传输的关键，它是由权威的CA机构颁布。如上图 GeoTrust 便是一个CA机构。证书的主要内容包含如下几点：公钥、证书发布机构、证书持有者、证书有效期、签名算法、 指纹 和 指纹算法 。

在网络传输中，要想实现自己的数据能够安全的传输，需要对请求数据进行加密。这样即使被数据包被截取，数据也不会被泄漏。

该证书是 CA机构 颁发给 申请者 的。

在网络传输中，若直接传输对称加密的秘钥。请求被拦截后，密钥也会泄露，造成信息泄露。所以HTTPS首先采取非对称加密方式，将公钥传输给浏览器。同时还会携带一些其他信息（这些信息组成证书）。

如下图所示，证书中 使用者 字段包含的内容时 csdnnet ，这个字段可以让浏览器供浏览器进行验证。（浏览器可以判定是否是目标服务器发送的证书，而非三方服务器发送的证书）。

服务器将该证书发送给浏览器的。

浏览器内置 CA机构 为 自己颁发的证书 。即 根证书 。

谷歌浏览器：设置-->高级-->管理证书--->受信任的根证书颁发机构

根证书是浏览器内置的。 根证书中携带的是CA的根公钥。 而根私钥是绝对保密的 。

CA机构颁发给申请者的CA证书中，存在一个 指纹 属性，该属性可以理解为证书身份的唯一标识。

指纹： 证书信息经过指纹算法sha1计算出hash值，然后使用 根密钥 进行加密。

https://wwwcnblogscom/MR-Guo/p/11447856html

TLS/SSL的功能实现主要依赖于 三类基本算法 ： 散列（哈希）函数 Hash 、 对称加密 和 非对称加密 ，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列（哈希）函数验证信息的完整性。

TCP握手建立链接后，客户端向服务端发送https请求前要握手一次，主要是认证服务端是否可信，与服务端协商后续传输数据的加密方式，以及校验完整性的签名方式（HASH）

解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA。简单的说，PKI就是浏览器和CA，CA是整个安全机制的重要保障，我们平时用的证书就是由CA机构颁发，其实就是 用CA的私钥给用户的证书签名 ，然后在证书的签名字段中填充这个签名值，浏览器在验证这个证书的时候就是使用CA的公钥进行验签。

在这个过程注意几点：

a申请证书不需要提供私钥， 确保私钥永远只能服务器掌握 ;

b证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名;

c内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说"部署自签SSL证书非常不安全"）

d 证书=公钥（服务方生成密码对中的公钥）+申请者与颁发者信息+签名（用CA机构生成的密码对的私钥进行签名） ;

即便有人截取服务器A证书，再发给客户端，想冒充服务器A，也无法实现。因为证书和url的域名是绑定的。

1）颁发证书，颁发证书其实就是使用CA的私钥对证书请求签名文件进行签名；

2）颁发的证书浏览器要信任，浏览器只需要用CA的公钥进行验签成功就表示这个证书是合法可信的，这就需要浏览器内置CA的公钥，也就是内置CA的证书。一般来说，操作系统都会内置权威CA的证书，有的浏览器会使用操作系统内置的CA证书列表，有的浏览器则自己维护的CA证书列表，比如Firefox。

如 CA根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的CA根证书验证合法即可。

a服务器证书 serverpem 的签发者为中间证书机构 inter，inter 根据证书 interpem 验证 serverpem 确实为自己签发的有效证书;

b中间证书 interpem 的签发 CA 为 root，root 根据证书 rootpem 验证 interpem 为自己签发的合法证书;

c客户端内置信任 CA 的 rootpem 证书，因此服务器证书 serverpem 的被信任。

服务器证书、中间证书与根证书在一起组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。

二级证书结构存在的优势：

a减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发;

b 根证书一般内置在客户端（浏览器或操作系统）中 ，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救;

c中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书;

d证书链四级以内一般不会对 HTTPS 的性能造成明显影响。

证书链有以下特点：

a同一本服务器证书可能存在多条合法的证书链。

因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;

b不同证书链的层级不一定相同，可能二级、三级或四级证书链。

中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。

交叉证书的应用场景是这样的：假如现在阿里云成为一个新的根CA机构，那阿里云签发的证书想要浏览器信任的话，阿里云的根证书就需要内置在各大操作系统和浏览器中，这需要较长时间的部署，那在没有完全部署完成之前，阿里云签发的证书怎么才能让浏览器信任呢，这就需要用到交叉证书了。

上图中，根证书A是一个所有浏览器都内置了的根证书，B是一个新的根证书，用户证书D是由根证书 B的二级CA B1来签发的，但是根证书B并没有在浏览器中内置，所以浏览器不会信任用户证书D，这是因为浏览器在验签时只验证到B1这一层然后找不到根证书B就无法验证下去了。

如果二级CA B1证书是由根证书A来签名，那这个问题就解了，所以新的根证书机构B会将二级CA证书（准确地讲是二级CA的证书签名请求文件）给老的根证书A来签名，然后得到一个新的中间证书就是交叉证书。

浏览器在验证的时侯用了新的信任链，这样就可以解决用户证书的信任问题。

当B的根证书全部部署完成后，再替换成自己的二级CA就可以了。

证书分有三类：DV、OV、EV

DV证书只校验域名的所有权，所以我们在申请DV证书的时候CA会提供几种验证域名所有权的方法：比如文件校验、DNS校验、邮件校验，DV证书支持单域名、多域名和泛域名，但不支持多个泛域名，只支持一个泛域名，一般价格比较便宜，具体价格跟域名的数量有关，域名越多价格越高。

OV证书要验证组织机构，在申请证书时CA会打电话确认这个域名是否真的属于相应的公司或者机构，OV证书是单域名、多域名、泛域名和多个泛域名都支持，价格一般比DV证书要贵。

EV证书的校验就更细了，比如组织机构的地址之类的，EV证书会在地址栏上显示组织机构的名称，EV证书只支持单域名或者多个域名，不支持泛域名，而且更贵，所以普通用户一般不会用EV证书。

证书是有生命周期的，如果证书的私钥泄漏了那这个证书就得吊销，一般有两种吊销方式：CRL和OCSP。

CRL（ Certificate Revocation List）是CA机构维护的一个已经被吊销的证书序列号列表，浏览器需要定时更新这个列表，浏览器在验证证书合法性的时候也会在证书吊销列表中查询是否已经被吊销，如果被吊销了那这个证书也是不可信的。可以看出，这个列表随着被吊销证书的增加而增加，列表会越来越大，浏览器还需要定时更新，实时性也比较差。

所以，后来就有了 OCSP （Online Certificate Status Protocol）在线证书状态协议，这个协议就是解决了 CRL 列表越来越大和实时性差的问题而生的。有了这个协议，浏览器就可以不用定期更新CRL了，在验证证书的时候直接去CA服务器实时校验一下证书有没有被吊销就可以，是解决了CRL的问题，但是每次都要去CA服务器上校验也会很慢，在网络环境较差的时候或者跨国访问的时候，体验就非常差了，OCSP虽然解决了CRL的问题但是性能却很差。

主要摘自

http://www360doccom/content/18/0606/20/13644263_760231690shtml

https://blogcsdnnet/hherima/article/details/52469360

https://blogcsdnnet/hherima/article/details/52469488

可以通过将证书导入到“受信任的根证书颁发机构”存储区中解决该问题。

1、win+r 运行mmc；

2、文件>添加删除管理单元；

3、在可用的管理单元中选择”证书“，点击添加-->确定；

4、在控制节点中展开证书-->受信任的证书颁发机构-->证书，右击所有任务-->导入；

5、最后，浏览文件导入你的证书即可。

扩展资源

CA根证书安装方法

在很多情况下，安装CA证书并不是必要的。大多数操作系统的CA证书是默认安装的。

下载和安装CA证书并没有真正的标准流程。采用的方法依赖于许多因素，如正在使用的服务器类型可作为一个证书颁发机构，证书颁发机构的配置方式以及设备上所使用的想安装CA证书的操作系统 。

如果Windows服务器被配置为一台证书颁发机构，通常情况下，管理员可通过一个Web界面生成并下载证书。这个Web界面的地址通常是https://<the server's FQDN>/CertSRV。该Web界面中有下载CA证书的选项。

如果一台Windows PC上安装了CA证书，该证书是由证书控制台进行安装的。在Windows 8个人电脑上，可以通过本地的运行功能进入CertLMmsc，从而访问证书商店。CA证书通常安装在第三方根认证机构容器中的受信任的根证书颁发机构中。

通常，如果想在移动设备上安装一个CA证书，可以将证书通过电子邮件发送到该移动设备上的邮箱账号。打开附件，证书将被安装到该设备上。

当然，还有一些特殊的证书，例如：网上报税使用的联通ca证书，就需要你手动安装导入到你的报税系统中，它是无法自动安装导入的。

参考资源：：ca证书

wtp=tt讲得很明白了。也非常通俗易懂根证书是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。从技术上讲，证书其实包含三部分，用户的信息，用户的公钥，还有CA中心对该证书里面的信息的签名，要验证一份证书的真伪（即验证CA中心对该证书信息的签名是否有效），需要用CA中心的公钥验证，而CA中心的公钥存在于对这份证书进行签名的证书内，故需要下载该证书，但使用该证书验证又需先验证该证书本身的真伪，故又要用签发该证书的证书来验证，这样一来就构成一条证书链的关系，这条证书链在哪里终结呢？答案就是根证书，根证书是一份特殊的证书，它的签发者是它本身，下载根证书就表明您对该根证书以下所签发的证书都表示信任，而技术上则是建立起一个验证证书信息的链条，证书的验证追溯至根证书即为结束。所以说用户在使用自己的数字证书之前必须先下载根证书。

根证书通常是离线的，签发证书的工作一般由中级根通过RA来完成。直接用根证书来签发终端用户证书在CA业界被普遍认为是不安全的。根证书服务器起不来，应该暂时不影响用户证书的签发。

在搭CA系统的时候，根证书按要求是必须要在加密卡里做备份的。如果备份没有做，先确认下服务器起不来是硬件问题还是系统问题。

硬件问题就更换硬件，系统问题可以尝试系统恢复。如果软硬件排查的工作都尝试过，还是无法恢复，根密钥也没有做恢复。。。那就只有新建一个根证书了！

新建的根证书可以跟原有的中级根证书做交叉认证，就是拿新的根对原有的中级根重新做签名。这样已经签发的证书无论在新根下面还是在老的根下面都是受信的。经过一段时间的缓冲，可以平滑的将老的根证书切换到新根下面。一般CA业界更新根证书也都是这么操作的。

推荐一下，用天威诚信的服务模式，建一个托管的CA系统。不必自建一套CA系统，也能够在本地使用证书注册服务器。

数字签名是一种用于信息 真实性 和 完整性 校验的手段，一套数字签名包含签名和验证两种运算。下面是一套简单的数字签名示意图。

数字签名使用 非对称加密 技术。每个人都有一对钥匙，私钥只有本人知道，公钥公开，私钥签名，公钥验签。

在进行信息传递时，信息发送者用私钥生成签名并将公钥一起发送给信息接收者，接收者使用公钥验签。上述过程中信息完整性得到校验，但发送者的身份是否合法无法得知（因为任何人都可以声称自己是合法的），因此引入了 身份认证机构 。

身份认证机构是 信息接收者 能信任的机构，所有的公钥必须向该机构进行注册。注册后身份认证机构给发送者颁发一 数字证书 。对文件签名后，发送者把此数字证书连同文件及签名一起发给信息接收者，接收者向身份认证机构求证是否真地是用发送者密钥签发的文件。

数字证书是一种电子档案，用来证明公钥拥有者的身份。此档案包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对该文件的数字签名。

证书的本质就是对公钥加数字签名，认证机构用自己的私钥对需要认证的人（或组织机构）的公钥进行数字签名并生成证书。

我们需要了解以下几种类型的证书

自签证书

用户可以自己生成数字证书，不过没有任何可信赖的人签名，它主要用于小范围测试，这种自签名证书通常不会被广泛信任，使用时可能会遇到电脑软件的安全警告。

根证书

根证书获得广泛认可，通常已预先安装在各种软体（包括操作系统、浏览器、电邮软件等），作为信任链的起点，来自于公认可靠的政府机关、证书颁发机构公司、非营利组织等，与各大软件商透过严谨的核认程序才在不同的软件广泛部署。由于部署程序复杂费时，需要行政人员的授权及机构法人身份的核认，一张根证书有效期可能长达二十年以上。在某些企业，也可能会在内部电脑自行安装企业自签的根证书，以支援内部网的企业级软件；但是这些证书可能未被广泛认可，只在企业内部适用。

中介证书

认证机构的一个重要任务就是为客户签发证书，虽然广泛认可的认证机构都已拥有根证书，相对应的私钥可用以签署其他证书，但因为密钥管理和行政考虑，一般会先行签发中介证书，才为客户作数位签署。中介证书的有效期会较根证书为短，并可能对不同类别的客户有不同的中介证书作分工。

TLS服务器证书

网站在互联网上提供服务时，域名就是服务器证书上主体，相关机构名称则写在组织或单位一栏上。证书和私钥会安装在服务器。客户端的软件（如浏览器）会执行认证路径验证算（Certification path validation algorithm）以确保安全，如果未能肯定加密通道是否安全（例如证书上的主体名称不对应网站域名、伺服器使用了自签证书、或加密算法不够强），可能会警告用户。

TLS客户端证书

客户端证书包含电子邮件地址或个人姓名，而不是主机名。客户端证书比较不常见，因为考虑到技术门槛及成本因素，通常都是由服务提供者验证客户身份，而不是依赖第三方认证机构。通常，需要使用到客户端证书的服务都是内部网的企业级软件，他们会设立自己的内部根证书，由企业的技术人员在企业内部的电脑安装相关客户端证书以便使用。在公开的互联网，大多数网站都是使用登入密码和Cookie来验证用户，而不是客户端证书。

根证书（自签证书）、中介证书和终端实体（TLS服务器/客户端）证书的形成如下信任链

证书一般遵从X509格式规范

证书可以二进制或 Base64 形式储存，常见的文件扩展名有cer、crt、der和pem。如果把证书和私钥一起储存，则可以使用PKCS#12（p12）格式。

我们在写对外 API 时，针对信息传递的安全考虑，做如下设计

我们使用 SHA256withRSA 进行签名，下面是一个Java简单例子

一般的CA证书，可以直接在WINDOWS上生成。通过点对点原理，实现数据的传输加密和身份核实功能。

服务器证书，是必须安装在服务器中，由服务器的软硬件信息生成的CSR文件，通过在微软和全球webTrust证书联盟的备份和核实后，生成的CA证书。网站能在IE浏览器上直接显示“安全锁”，和显示证书信息。高级的版本能在浏览器地址栏变绿色，是目前全球最有效果的身份核实、信息加密工具。 

服务器证书和CA证书是否一样

本质上是一样的，只是不同的名字。前者是从技术角度命名，后者是从用途角度命名的，都是为网站的机密数据提供加密传输功能，从而确保机密信息的机密性、完整性和不可否认性。