不少关于CA证书的讲解。html
1.什么是CA证书。git
看过一些博客,写的比较形象具体。算法
◇ 普通的介绍信浏览器
想必大伙儿都据说过介绍信的例子吧?假设 A 公司的张三先生要到 B 公司去拜访,可是 B 公司的全部人都不认识他,他咋办捏?经常使用的办法是带公司开的一张介绍信,在信中说:兹有张三先生前往贵公司办理业务,请给予接洽......
云云。而后在信上敲上A公司的公章。安全
张三先生到了 B 公司后,把介绍信递给 B 公司的前台李四小姐。李小姐一看介绍信上有 A 公司的公章,并且 A 公司是常常和 B 公司有业务往来的,这位李小姐就相信张先生不是歹人了。服务器
这里,A公司就是CA证书tcp
◇ 引入中介机构的介绍信函数
好,回到刚才的话题。若是和 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 证书。
2.证书的签发过程:
a.服务方 S 向第三方机构CA提交公钥、组织信息、我的信息(域名)等信息并申请认证;
b.CA 经过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的全部权等;
c.如信息审核经过,CA 会向申请者签发认证文件-证书。
证书包含如下信息:申请者公钥、申请者的组织信息和我的信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文,同时包含一个签名;
签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,而后,采用 CA 的私钥对信息摘要进行加密,密文即签名;
d.客户端 C 向服务器 S 发出请求时,S 返回证书文件;
e.客户端 C 读取证书中的相关的明文信息,采用相同的散列函数计算获得信息摘要,而后,利用对应 CA 的公钥解密签名数据,对比证书的信息摘要,若是一致,则能够确认证书的合法性,即公钥合法;
f.客户端而后验证证书相关的域名信息、有效时间等信息;
g.客户端会内置信任 CA 的证书信息(包含公钥),若是CA不被信任,则找不到对应 CA 的证书,证书也会被断定非法。
在这个过程注意几点:
1.申请证书不须要提供私钥,确保私钥永远只能服务器掌握;
2.证书的合法性仍然依赖于非对称加密算法,证书主要是增长了服务器信息以及签名;
3.内置 CA 对应的证书称为根证书,颁发者和使用者相同,本身为本身签名,即自签名证书;
4.证书=公钥+申请者与颁发者信息+签名;
3.http存在的问题(引用:http://blog.csdn.net/wangjun5159/article/details/51510594)
后续内容的须要,这里插播一段共享密钥加密和公开密钥加密
https很好的解决了http的三个缺点(被监听、被篡改、被假装),https不是一种新的协议,它是http+SSL(TLS)的结合体,SSL是一种独立协议,因此其它协议好比smtp等也能够跟ssl结合。https改变了通讯方式,它由之前的http—–>tcp,改成http——>SSL—–>tcp;https采用了共享密钥加密+公开密钥加密的方式
4.比较完整的过程:
1. 客户端发起HTTPS请求
这个没什么好说的,就是用户在浏览器里输入一个https网址,而后链接到server的443端口。
2. 服务端的配置
采用HTTPS协议的服务器必需要有一套数字证书,能够本身制做,也能够向组织申请。区别就是本身颁发的证书须要客户端验证经过,才能够继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择,有1年的免费服务)。这套证书其实就是一对公钥和私钥。若是对公钥和私钥不太理解,能够想象成一把钥匙和一个锁头,只是全世界只有你一我的有这把钥匙,你能够把锁头给别人,别人能够用这个锁把重要的东西锁起来,而后发给你,由于只有你一我的有这把钥匙,因此只有你才能看到被这把锁锁起来的东西。
3. 传送证书
这个证书其实就是公钥,只是包含了不少信息,如证书的颁发机构,过时时间等等。
4. 客户端解析证书
这部分工做是有客户端的TLS来完成的,首先会验证公钥是否有效,好比颁发机构,过时时间等等,若是发现异常,则会弹出一个警告框,提示证书存在问题。若是证书没有问题,那么就生成一个随机值。而后用证书对该随机值进行加密。就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,否则看不到被锁住的内容。
5. 传送加密信息
这部分传送的是用证书加密后的随机值,目的就是让服务端获得这个随机值,之后客户端和服务端的通讯就能够经过这个随机值来进行加密解密了。
6. 服务段解密信息
服务端用私钥解密后,获得了客户端传过来的随机值(私钥),而后把内容经过该值进行对称加密。所谓对称加密就是,将信息和私钥经过某种算法混合在一块儿,这样除非知道私钥,否则没法获取内容,而正好客户端和服务端都知道这个私钥,因此只要加密算法够彪悍,私钥够复杂,数据就够安全。
7. 传输加密后的信息
这部分信息是服务段用私钥加密后的信息,能够在客户端被还原。
8. 客户端解密信息
客户端用以前生成的私钥解密服务段传过来的信息,因而获取了解密后的内容。整个过程第三方即便监听到了数据,也一筹莫展。
5.总结整个过程:
1.服务器向CA机构获取证书(假设这个证书伪造不了),当浏览器首次请求服务器的时候,服务器返回证书给浏览器。(证书包含:公钥+申请者与颁发者的相关信息+签名)
2.浏览器获得证书后,开始验证证书的相关信息,证书有效(没过时等)。(验证过程,比较复杂,详见上文)。
3.验证完证书后,若是证书有效,客户端是生成一个随机数,而后用证书中的公钥进行加密,加密后,发送给服务器,服务器用私钥进行解密,获得随机数。以后双方便开始用该随机数做为钥匙,对要传递的数据进行加密、解密。
关于https:http://blog.csdn.net/wangjun5159/article/details/51510594
引用参考博客:http://kb.cnblogs.com/page/194742/
关于https的误解:http://www.admin5.com/article/20150523/600106.shtml