如何鉴别数字证书的真伪？得到了服务器的证书是否可以确定该服务器可信

可以通过以下方法鉴别数字证书的可信度：

点击开证书，看看里面的证书颁发机构，然后是在网上搜搜是不是知名的颁发机构。

值得一提，颁发机构如果是证书使用者自己的话，那么这是一张自签证书，是不具备可信度的。

如果确定了证书是一张服务器证书，要通过查看证书上面的信息，才能确定服务器是否可信。如果还有什么关于证书的问题，可以向沃通证书签发中心咨询。

1打开证书管理工具

在Windows操作系统中，打开控制面板，选择管理工具下的证书，进入证书管理界面。在Linux和MacOS中，可以通过命令行或者相应的图形界面来打开证书管理工具。

2找到需要导出的证书并双击

在证书管理列表中，找到需要导出的证书，右键单击并选择“导出”。在弹出的对话框中，选择要导出的证书格式（通常有PEM、DER、PFX等格式），设置密码以及导出文件保存的路径和名称。

想必大伙儿都听说过介绍信的例子吧？假设 A 公司的张三先生要到 B 公司去拜访，但是 B 公司的所有人都不认识他，他咋办捏？常用的办法是带公司开的一张介绍信，在信中说：兹有张三先生前往贵公司办理业务，请给予接洽云云。然后在信上敲上A公司的公章。

张三先生到了 B 公司后，把介绍信递给 B 公司的前台李四**。李**一看介绍信上有 A 公司的公章，而且 A 公司是经常和 B 公司有业务往来的，这位李**就相信张先生不是歹人了。

这里，A公司就是CA证书

◇ 引入中介机构的介绍信

好，回到刚才的话题。如果和 B 公司有业务往来的公司很多，每个公司的公章都不同，那前台就要懂得分辨各种公章，非常滴麻烦。所以，有某个中介公司 C，发现了这个商机。C公司专门开设了一项“代理公章”的业务。

今后，A 公司的业务员去 B 公司，需要带2个介绍信：

介绍信1

含有 C 公司的公章及 A 公司的公章。并且特地注明：C 公司信任 A 公司。

介绍信2

仅含有 A 公司的公章，然后写上：兹有张三先生前往贵公司办理业务，请给予接洽云云。

某些不开窍的同学会问了，这样不是增加麻烦了吗？有啥好处捏？

主要的好处在于，对于接待公司的前台，就不需要记住各个公司的公章分别是啥样子的；他/她只要记住中介公司 C 的公章即可。当他/她拿到两份介绍信之后，先对介绍信1的 C 公章，验明正身；确认无误之后，再比对介绍信1和介绍信2的两个 A 公章是否一致。如果是一样的，那就可以证明介绍信2是可以信任的了。

“证书”洋文也叫“digital certificate”或“public key certificate”（专业的解释看“ 这里 ”）。

它是用来证明某某东西确实是某某东西的东西（是不是像绕口令？）。通俗地说，证书就好比例子里面的公章。通过公章，可以证明该介绍信确实是对应的公司发出的。

理论上，人人都可以找个证书工具，自己做一个证书。那如何防止坏人自己制作证书出来骗人捏？请看后续 CA 的介绍。

◇ 什么是CA？

CA是Certificate Authority的缩写，也叫“证书授权中心”。（专业的解释看“ 这里 ”）

它是负责管理和签发证书的第三方机构，就好比例子里面的中介——C 公司。一般来说，CA必须是所有行业和所有公众都信任的、认可的。因此它必须具有足够的权威性。就好比A、B两公司都必须信任C公司，才会找 C 公司作为公章的中介。

CA 证书，顾名思义，就是CA颁发的证书。

前面已经说了，人人都可以找工具制作证书。但是你一个小破孩制作出来的证书是没啥用处的。因为你不是权威的CA机关，你自己搞的证书不具有权威性。

这就好比上述的例子里，某个坏人自己刻了一个公章，盖到介绍信上。但是别人一看，不是受信任的中介公司的公章，就不予理睬。坏蛋的阴谋就不能得逞啦。

文本后续提及的证书，若无特殊说明，均指 CA 证书。

证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；

签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名；

在这个过程注意几点：

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

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

3内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书；

4证书=公钥+申请者与颁发者信息+签名；

后续内容的需要，这里插播一段共享密钥加密和公开密钥加密

https很好的解决了http的三个缺点（被监听、被篡改、被伪装），https不是一种新的协议，它是http+SSL(TLS)的结合体，SSL是一种独立协议，所以其它协议比如smtp等也可以跟ssl结合。https改变了通信方式，它由以前的http—–>tcp，改为http——>SSL—–>tcp；https采用了共享密钥加密+公开密钥加密的方式

4比较完整的过程：

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5 传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6 服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

8 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

1服务器向CA机构获取证书（假设这个证书伪造不了），当浏览器首次请求服务器的时候，服务器返回证书给浏览器。（证书包含：公钥+申请者与颁发者的相关信息+签名）

2浏览器得到证书后，开始验证证书的相关信息，证书有效（没过期等）。（验证过程，比较复杂，详见上文）。

3验证完证书后，如果证书有效，客户端是生成一个随机数，然后用证书中的公钥进行加密，加密后，发送给服务器，服务器用私钥进行解密，得到随机数。之后双方便开始用该随机数作为钥匙，对要传递的数据进行加密、解密。

关于https： http://blogcsdnnet/wangjun5159/article/details/51510594

引用参考博客： http://kbcnblogscom/page/194742/

关于https的误解： http://wwwadmin5com/article/20150523/600106shtml

数字证书中主题(Subject)中字段的含义

何为SSL/TLS单向认证，双向认证？

单向认证 指的是只有一个对象校验对端的证书合法性。

通常都是client来校验服务器的合法性。那么client需要一个cacrt,服务器需要servercrt,serverkey

双向认证 指的是相互校验，服务器需要校验每个client,client也需要校验服务器。

server 需要 serverkey 、servercrt 、cacrt

client 需要 clientkey 、clientcrt 、cacrt

HTTPS 的实现原理

大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实，HTTPS在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

HTTPS的整体过程分为证书验证和数据传输阶段，具体的交互过程如下：

① 证书验证阶段

浏览器发起 HTTPS 请求

服务端返回 HTTPS 证书

客户端验证证书是否合法，如果不合法则提示告警

② 数据传输阶段

当证书验证合法后，在本地生成随机数

通过公钥加密随机数，并把加密后的随机数传输到服务端

服务端通过私钥对随机数进行解密

服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

为什么数据传输是用对称加密？

首先，非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

为什么需要 CA 认证机构颁发证书？

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的 “中间人攻击” 问题。 

“中间人攻击”的具体过程如下：

过程原理：

本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器

中间人服务器返回中间人自己的证书

客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输

中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密

中间人以客户端的请求内容再向正规网站发起请求

因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据

中间人凭借与正规网站建立的对称加密算法对内容进行解密

中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输

客户端通过与中间人建立的对称加密算法对返回结果数据进行解密

由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。

浏览器是如何确保 CA 证书的合法性？

1 证书包含什么信息？

颁发机构信息

公钥

公司信息

域名

有效期

指纹

……

2 证书的合法性依据是什么？

首先，权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构。另外，证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。

3 浏览器如何验证证书的合法性？

浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：

验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；

判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证； 

判断证书是否被篡改。需要与 CA 服务器进行校验；

判断证书是否已吊销。通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率

以上任意一步都满足的情况下浏览器才认为证书是合法的。这里插一个我想了很久的但其实答案很简单的问题： 

既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据进行解密。

4 只有认证机构可以生成证书吗？

如果需要浏览器不提示安全风险，那只能使用认证机构签发的证书。但浏览器通常只是提示安全风险，并不限制网站不能访问，所以从技术上谁都可以生成证书，只要有证书就可以完成网站的HTTPS 传输。例如早期的 12306 采用的便是手动安装私有证书的形式实现 HTTPS 访问。 

本地随机数被窃取怎么办？

证书验证是采用非对称加密实现，但是传输过程是采用对称加密，而其中对称加密算法中重要的随机数是由本地生成并且存储于本地的HTTPS

如何保证随机数不会被窃取？其实 HTTPS 并不包含对随机数的安全保证，HTTPS保证的只是传输过程安全，而随机数存储于本地，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。

用了 HTTPS 会被抓包吗？

HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。通常HTTPS抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。

既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？ 

HTTPS可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。

总结

以下用简短的Q&A形式进行全文总结：

Q: HTTPS 为什么安全？ 

A: 因为 HTTPS 保证了传输安全，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性。

Q: HTTPS 的传输过程是怎样的？ 

A: 客户端发起 HTTPS

请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于改造对称加密算法的随机数，通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。

Q: 为什么需要证书？ 

A: 防止”中间人“攻击，同时可以为网站提供身份证明。

Q: 使用 HTTPS 会被抓包吗？ 

A: 会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

分享一张详细的过程图：

https证书（也称为ssl证书）是需要去正规的CA机构进行申请的，步骤如下：

第一步：将CSR提交到代理商

CSR(Certificate Signing Request)文件必须由用户自己生成，也可以利用在线CSR生成工具。选择要申请的产品，提交一个新的订单，并将制作好的CSR文件提交。

第二步 资料提交到CA

当收到您的订单和CSR后，如果是域名验证型证书(DV SSL证书)，在域名验证之后10分钟左右就可颁发证书，若是其他类型证书则是需要通过CA机构进行验证之后才可颁发。

第三步 发送验证邮件到管理员邮箱

权威CA机构获得资料后，将发送一封确认信到管理员邮箱，信中将包含一个 对应的链接过去。每一个订单，都有一个唯一的PIN以做验证用。

第四步 邮件验证

点击确认信中的链接，可以访问到CA机构验证网站，在验证网站，可以看到该订单的申请资料，然后点击”I Approve”完成邮件验证。

第五步 颁发证书

在用户完成邮件验证之后，CA机构会将证书通过邮件方式发送到申请人自己的邮箱，当用户收到证书后直接安装就可以了。若安装存在问题，我们是提供免费证书安装服务的。

1、按下 Windows + R 键打开“运行”，输入“mmc”，点击“确认”，打开控制台；

2、点击“文件=》添加/删除管理单元”；

3、在弹出的窗口左侧列表中选中“证书”在点击“添加”；

4、在证书管理单元的账户中选择“我的用户账户”，点击“完成”；

5、右侧列表有“证书”单元以后，在点击“确认”；

6、展开“证书”=》“受信任的根证书颁发机构”=》“证书” ，在右侧列表中查找你需要删除的证书，然后在将其删除；

7、在重新打开需要证书的网站，这是网站会提示需要安装证书，直接点击“查看证书”，点击“安装证书”=》“安装到受信任的根证书颁发机构”即可。

当访问一些包含HTTPS类的页面的时候统一提示“此连接不受信任”

原因：

1：可能是由于缓存导致，清空所有缓存(可能性不高)；

2：数字证书不正确，安装正确的数字证书（这个是个别网站提示不信任，高可能性）；

3：在浏览器选项下面的高级——加密，勾上 SSL和TLS（存在可能性）；

4：安全软件过滤掉相关网站(可能性不高)；

5：如果任何网站都提示不受信任，更多可能性是由于系统时间不对（高可能性）！！