密码和证书-与证书相关的名称(SSL,X.509,PEM,DER,CRT,CER,KEY,CSR,P12等)

之前没接触过证书加密的话,对证书相关的这些概念真是感觉挺棘手的,因为一下子来了一大堆新名词,看起来像是另一个领域的东西,而不是我们所熟悉的编程领域的那些东西,起码我个人感觉如此,且很长时间都没怎么搞懂.写这篇文章的目的就是为了理理清这些概念,搞清楚它们的含义及关联,还有一些基本操作。

SSL

SSL – Secure Sockets Layer,现在应该叫”TLS”,但由于习惯问题,我们还是叫”SSL”比较多.http协议默认情况下是不加密内容的,这样就很可能在内容传播的时候被别人监听到,对于安全性要求较高的场合,必须要加密,https就是带加密的http协议,而https的加密是基于SSL的,它执行的是一个比较下层的加密,也就是说,在加密前,你的服务器程序在干嘛,加密后也一样在干嘛,不用动,这个加密对用户和开发者来说都是透明的.More:[维基百科]

OpenSSL – 简单地说,OpenSSL是SSL的一个实现,SSL只是一种规范.理论上来说,SSL这种规范是安全的,目前的技术水平很难破解,但SSL的实现就可能有些漏洞,如著名的”心脏出血”.OpenSSL还提供了一大堆强大的工具软件,强大到90%我们都用不到.

证书标准

X.509 – 这是一种证书标准,主要定义了证书中应该包含哪些内容.其详情可以参考RFC5280,SSL使用的就是这种证书标准.

编码格式

同样的X.509证书,可能有不同的编码格式,目前有以下两种编码格式.

PEM – Privacy Enhanced Mail,打开看文本格式,以”—–BEGIN…”开头, “—–END…”结尾,内容是BASE64编码.
查看PEM格式证书的信息:openssl x509 -in certificate.pem -text -noout
Apache和*NIX服务器偏向于使用这种编码格式.

DER – Distinguished Encoding Rules,打开看是二进制格式,不可读.
查看DER格式证书的信息:openssl x509 -in certificate.der -inform der -text -noout
Java和Windows服务器偏向于使用这种编码格式.

相关的文件扩展名

这是比较误导人的地方,虽然我们已经知道有PEM和DER这两种编码格式,但文件扩展名并不一定就叫”PEM”或者”DER”,常见的扩展名除了PEM和DER还有以下这些,它们除了编码格式可能不同之外,内容也有差别,但大多数都能相互转换编码格式.

CRT – CRT应该是certificate的三个字母,其实还是证书的意思,常见于*NIX系统,有可能是PEM编码,也有可能是DER编码,大多数应该是PEM编码,相信你已经知道怎么辨别.

CER – 还是certificate,还是证书,常见于Windows系统,同样的,可能是PEM编码,也可能是DER编码,大多数应该是DER编码.

KEY – 通常用来存放一个公钥或者私钥,并非X.509证书,编码同样的,可能是PEM,也可能是DER.
查看KEY的办法:openssl rsa -in mykey.key -text -noout
如果是DER格式的话,同理应该这样了:openssl rsa -in mykey.key -text -noout -inform der

CSR – Certificate Signing Request,即证书签名请求,这个并不是证书,而是向权威证书颁发机构获得签名证书的申请,其核心内容是一个公钥(当然还附带了一些别的信息),在生成这个申请的时候,同时也会生成一个私钥,私钥要自己保管好.做过iOS APP的朋友都应该知道是怎么向苹果申请开发者证书的吧.
查看的办法:openssl req -noout -text -in my.csr (如果是DER格式的话照旧加上-inform der,这里不写了)

PFX/P12 – predecessor of PKCS#12,对*nix服务器来说,一般CRT和KEY是分开存放在不同文件中的,但Windows的IIS则将它们存在一个PFX文件中,(因此这个文件包含了证书及私钥)这样会不会不安全?应该不会,PFX通常会有一个”提取密码”,你想把里面的东西读取出来的话,它就要求你提供提取密码,PFX使用的时DER编码,如何把PFX转换为PEM编码?
openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
这个时候会提示你输入提取代码. for-iis.pem就是可读的文本.
生成pfx的命令类似这样:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt

其中CACert.crt是CA(权威证书颁发机构)的根证书,有的话也通过-certfile参数一起带进去.这么看来,PFX其实是个证书密钥库.

JKS – 即Java Key Storage,这是Java的专利,跟OpenSSL关系不大,利用Java的一个叫”keytool”的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS,不过在此就不多表了.

证书编码的转换

PEM转为DER  openssl x509 -in cert.crt -outform der -out cert.der

DER转为PEM openssl x509 -in cert.crt -inform der -outform pem -out cert.pem

(提示:要转换KEY文件也类似,只不过把x509换成rsa,要转CSR的话,把x509换成req…)

获得证书

向权威证书颁发机构申请证书

用这命令生成一个csr: openssl req -newkey rsa:2048 -new -nodes -keyout my.key -out my.csr
把csr交给权威证书颁发机构,权威证书颁发机构对此进行签名,完成.保留好csr,当权威证书颁发机构颁发的证书过期的时候,你还可以用同样的csr来申请新的证书,key保持不变.

或者生成自签名的证书
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem

在生成证书的过程中会要你填一堆的东西,其实真正要填的只有Common Name,通常填写你服务器的域名,如”yourcompany.com”,或者你服务器的IP地址,其它都可以留空的.
生产环境中还是不要使用自签的证书,否则浏览器会不认,或者如果你是企业应用的话能够强制让用户的浏览器接受你的自签证书也行.向权威机构要证书通常是要钱的,但现在也有免费的,仅仅需要一个简单的域名验证即可.有兴趣的话查查”沃通数字证书”.

 

来自:https://www.cnblogs.com/guogangj/p/4118605.html

密码和证书-数字签名概述及与数字证书的关系

数字签名是什么?

1、鲍勃有两把钥匙,一把是公钥,另一把是私钥。

2、鲍勃把公钥送给他的朋友们—-帕蒂、道格、苏珊—-每人一把。

3、苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密,就可以达到保密的效果。

4、鲍勃收信后,用私钥解密,就看到了信件内容。这里要强调的是,只要鲍勃的私钥不泄露,这封信就是安全的,即使落在别人手里,也无法解密。

5、鲍勃给苏珊回信,决定采用”数字签名”。他写完后先用Hash函数,生成信件的摘要(digest)。

6、然后,鲍勃使用私钥,对这个摘要加密,生成”数字签名”(signature)。

7、鲍勃将这个签名,附在信件下面,一起发给苏珊。

8、苏珊收信后,取下数字签名,用鲍勃的公钥解密,得到信件的摘要。由此证明,这封信确实是鲍勃发出的。

9、苏珊再对信件本身使用Hash函数,将得到的结果,与上一步得到的摘要进行对比。如果两者一致,就证明这封信未被修改过。

10、复杂的情况出现了。道格想欺骗苏珊,他偷偷使用了苏珊的电脑,用自己的公钥换走了鲍勃的公钥。此时,苏珊实际拥有的是道格的公钥,但是还以为这是鲍勃的公钥。因此,道格就可以冒充鲍勃,用自己的私钥做成”数字签名”,写信给苏珊,让苏珊用假的鲍勃公钥进行解密。

11、后来,苏珊感觉不对劲,发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法,要求鲍勃去找”证书中心”(certificate authority,简称CA),为公钥做认证。证书中心用自己的私钥,对鲍勃的公钥和一些相关信息一起加密,生成”数字证书”(Digital Certificate)。

12、鲍勃拿到数字证书以后,就可以放心了。以后再给苏珊写信,只要在签名的同时,再附上数字证书就行了。

13、苏珊收信后,用CA的公钥解开数字证书,就可以拿到鲍勃真实的公钥了,然后就能证明”数字签名”是否真的是鲍勃签的。


原作者:David Youd

来自翻译:阮一峰

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

原文网址:http://www.youdzone.com/signature.html

密码和证书-https(ssl/tls)之协议概述和运行机制

一、相关加密算法

1)对称加密算法:就是加密和解密使用同一个密钥的加密算法。因为加密方和解密方使用的密钥相同,所以称为称为对称加密,也称为单钥加密方法。

优点是:加密和解密运算速度快,所以对称加密算法通常在消息发送方需要加密大量数据时使用;
缺点是:安全性差,如果一方的密钥遭泄露,那么整个通信就会被破解。另外加密之前双方需要同步密钥;
常用对称加密算法有:DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等;

2)非对称加密算法:而非对称加密算法需要两个密钥来进行加密和解密,这两个秘钥是公开密钥(public key,简称公钥)和私有密钥(private key,简称私钥)。

公钥和私钥是一对:公钥用来加密,私钥解密,而且公钥是公开的,私钥是自己保存的,不需要像对称加密那样在通信之前要先同步秘钥。

优点是:安全性更好,私钥是自己保存的,不需要像对称加密那样在通信之前要先同步秘钥。
缺点是:加密和解密花费时间长、速度慢,只适合对少量数据进行加密。
常用的非对称加密算法有:RSA、Elgamal、Rabin、D-H、ECC等;

3)HASH算法:也称为消息摘要算法。将任意长度的二进制值映射为较短的固定长度的二进制值,该二进制值称为哈希值。

常用于检验数据的完整性,检验数据没有被篡改过。常见的又 MD5(MD系列),SHA-1(SHA系列)

二、HTTP概述

首先,HTTP 是一个网络协议,是专门用来帮你传输 Web 内容滴。关于这个协议,就算你不了解,至少也听说过吧?比如访问百度主页,浏览器地址栏会出现如下的网址
http://www.baidu.com/
俺加了粗体的部分就是指 HTTP 协议。大部分网站都是通过 HTTP 协议来传输 Web 页面、以及 Web 页面上包含的各种东东(图片、CSS 样式、JS 脚本)。

 2.1. HTTP 的版本和历史
如今咱们用的 HTTP 协议,版本号是 1.1(也就是 HTTP 1.1)。这个 1.1 版本是1995年底开始起草的(技术文档是 RFC2068),并在1999年正式发布(技术文档是 RFC2616)。
在 1.1 之前,还有曾经出现过两个版本“0.9 和 1.0”,其中的 HTTP 0.9 【没有】被广泛使用,而 HTTP 1.0 被广泛使用过。
另外,2015年 IETF 发布了 HTTP 2.0 (技术文档是 RFC7540

 2.2. HTTP 和 TCP 之间的关系
简单地说,TCP 协议是 HTTP 协议的基石——HTTP 协议需要依靠 TCP 协议来传输数据。
在网络分层模型中,TCP 被称为“传输层协议”,而 HTTP 被称为“应用层协议”。有很多常见的应用层协议是以 TCP 为基础的,比如“FTP、SMTP、POP、IMAP”等。
TCP 被称为“面向连接”的传输层协议。关于它的具体细节,俺就不展开了(否则篇幅又失控了)。你只需知道:传输层主要有两个协议,分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 协议想象成某个水管,发送端这头进水,接收端那头就出水。并且 TCP 协议能够确保,先发送的数据先到达(与之相反,UDP 不保证这点)。

 2.3. HTTP 协议如何使用 TCP 连接?
HTTP 对 TCP 连接的使用,分为两种方式:俗称“短连接”和“长连接”(“长连接”又称“持久连接”,洋文叫做“Keep-Alive”或“Persistent Connection”)
假设有一个网页,里面包含好多图片,还包含好多【外部的】CSS 文件和 JS 文件。在“短连接”的模式下,浏览器会先发起一个 TCP 连接,拿到该网页的 HTML 源代码(拿到 HTML 之后,这个 TCP 连接就关闭了)。然后,浏览器开始分析这个网页的源码,知道这个页面包含很多外部资源(图片、CSS、JS)。然后针对【每一个】外部资源,再分别发起一个个 TCP 连接,把这些文件获取到本地(同样的,每抓取一个外部资源后,相应的 TCP 就断开)
相反,如果是“长连接”的方式,浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后,该 TCP 连接并不会立即关闭,而是暂时先保持着(所谓的“Keep-Alive”)。然后浏览器分析 HTML 源码之后,发现有很多外部资源,就用刚才那个 TCP 连接去抓取此页面的外部资源。

在 HTTP 1.0 版本,【默认】使用的是“短连接”(那时候是 Web 诞生初期,网页相对简单,“短连接”的问题不大);
到了1995年底开始制定 HTTP 1.1 草案的时候,网页已经开始变得复杂(网页内的图片、脚本越来越多了)。这时候再用短连接的方式,效率太低下了(因为建立 TCP 连接是有“时间成本”和“CPU 成本”滴)。所以,在 HTTP 1.1 中,【默认】采用的是“Keep-Alive”的方式。
关于“Keep-Alive”的更多介绍,可以参见维基百科词条(在“这里”)

三、SSL/TLS概述

SSL 是洋文“Secure Sockets Layer”的缩写,中文叫做“安全套接层”。它是在上世纪90年代中期,由网景公司设计的。(顺便插一句,网景公司不光发明了 SSL,还发明了很多 Web 的基础设施——比如“CSS 样式表”和“JS 脚本”)
为啥要发明 SSL 这个协议捏?因为原先互联网上使用的 HTTP 协议是明文的,存在很多缺点——比如传输内容会被偷窥(嗅探)和篡改。发明 SSL 协议,就是为了解决这些问题。
到了1999年,SSL 因为应用广泛,已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS(是“Transport Layer Security”的缩写),中文叫做“传输层安全协议”。
很多相关的文章都把这两者并列称呼(SSL/TLS),因为这两者可以视作同一个东西的不同阶段。

1994年,NetScape公司设计了SSL协议(Secure Sockets Layer)的1.0版,但是未发布。
1995年,NetScape公司发布SSL 2.0版,很快发现有严重漏洞。
1996年,SSL 3.0版问世,得到大规模应用。
1999年,互联网标准化组织ISOC接替NetScape公司,发布了SSL的升级版TLS 1.0版。
2006年和2008年,TLS进行了两次升级,分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。

目前,应用最广泛的是TLS 1.0,接下来是SSL 3.0。但是,主流浏览器都已经实现了TLS 1.2的支持。
TLS 1.0通常被标示为SSL 3.1,TLS 1.1为SSL 3.2,TLS 1.2为SSL 3.3。

四、CA证书概述

数字证书 里面存放了公钥,(采用数字证书是为了防止别人篡改非对称加密算法的公钥,保证公钥的可信)具体可参见密码和证书-https(ssl/tls)之证书的概述及获取和网站部署

五、https概述

HTTPS其实是有两部分组成:HTTP + SSL / TLS,也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过SSL / TLS进行加密,所以传输的数据都是加密后的数据。

不使用SSL/TLS的HTTP通信,就是不加密的通信。所有信息明文传播,带来了三大风险。

(1) 窃听风险(eavesdropping):第三方可以获知通信内容。
(2) 篡改风险(tampering):第三方可以修改通信内容。
(3) 冒充风险(pretending):第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的,希望达到:

(1) 所有信息都是加密传播,第三方无法窃听。
(2) 具有校验机制,一旦被篡改,通信双方会立刻发现。
(3) 配备身份证书,防止身份被冒充。

互联网是开放环境,通信双方都是未知身份,这为协议的设计带来了很大的难度。而且,协议还必须能够经受所有匪夷所思的攻击,这使得SSL/TLS协议变得异常复杂。


★HTTPS 协议的需求是啥?

花了好多口水,终于把背景知识说完了。下面正式进入正题。先来说说当初设计 HTTPS 是为了满足哪些需求?
很多介绍 HTTPS 的文章一上来就给你讲实现细节。个人觉得:这是不好的做法。早在2009年开博的时候,发过一篇《学习技术的三部曲:WHAT、HOW、WHY》,其中谈到“WHY 型问题”的重要性。一上来就给你讲协议细节,你充其量只能知道 WHAT 和 HOW,无法理解 WHY。俺在前一个章节讲了“背景知识”,在这个章节讲了“需求”,这就有助于你理解:当初为什么要设计成这样?——这就是 WHY 型的问题。

◇兼容性

因为是先有 HTTP 再有 HTTPS。所以,HTTPS 的设计者肯定要考虑到对原有 HTTP 的兼容性。
这里所说的兼容性包括很多方面。比如已有的 Web 应用要尽可能无缝地迁移到 HTTPS;比如对浏览器厂商而言,改动要尽可能小;……
基于“兼容性”方面的考虑,很容易得出如下几个结论:
1. HTTPS 还是要基于 TCP 来传输
(如果改为 UDP 作传输层,无论是 Web 服务端还是浏览器客户端,都要大改,动静太大了)
2. 单独使用一个新的协议,把 HTTP 协议包裹起来
(所谓的“HTTP over SSL”,实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制,基本上原封不动)

打个比方:如果原来的 HTTP 是塑料水管,容易被戳破;那么如今新设计的 HTTPS 就像是在原有的塑料水管之外,再包一层金属水管。一来,原有的塑料水管照样运行;二来,用金属加固了之后,不容易被戳破。

◇可扩展性

前面说了,HTTPS 相当于是“HTTP over SSL”。
如果 SSL 这个协议在“可扩展性”方面的设计足够牛逼,那么它除了能跟 HTTP 搭配,还能够跟其它的应用层协议搭配。岂不美哉?
现在看来,当初设计 SSL 的人确实比较牛。如今的 SSL/TLS 可以跟很多常用的应用层协议(比如:FTP、SMTP、POP、Telnet)搭配,来强化这些应用层协议的安全性。

接着刚才打的比方:如果把 SSL/TLS 视作一根用来加固的金属管,它不仅可以用来加固输水的管道,还可以用来加固输煤气的管道。

◇保密性(防泄密)

HTTPS 需要做到足够好的保密性。
说到保密性,首先要能够对抗嗅探(行话叫 Sniffer)。所谓的“嗅探”,通俗而言就是监视你的网络传输流量。如果你使用明文的 HTTP 上网,那么监视者通过嗅探,就知道你在访问哪些网站的哪些页面。
嗅探是最低级的攻击手法。除了嗅探,HTTPS 还需要能对抗其它一些稍微高级的攻击手法——比如“重放攻击”(后面讲协议原理的时候,会再聊)。

◇完整性(防篡改)

除了“保密性”,还有一个同样重要的目标是“确保完整性”。关于“完整性”这个概念,在之前的博文《扫盲文件完整性校验——关于散列值和数字签名》中大致提过。健忘的同学再去温习一下。
在发明 HTTPS 之前,由于 HTTP 是明文的,不但容易被嗅探,还容易被篡改。
举个例子:
比如咱们天朝的网络运营商(ISP)都比较流氓,经常有网友抱怨说访问某网站(本来是没有广告的),竟然会跳出很多中国电信的广告。为啥会这样捏?因为你的网络流量需要经过 ISP 的线路才能到达公网。如果你使用的是明文的 HTTP,ISP 很容易就可以在你访问的页面中植入广告。
所以,当初设计 HTTPS 的时候,还有一个需求是“确保 HTTP 协议的内容不被篡改”。

◇真实性(防假冒)

在谈到 HTTPS 的需求时,“真实性”经常被忽略。其实“真实性”的重要程度不亚于前面的“保密性”和“完整性”。
举个例子:
你因为使用网银,需要访问该网银的 Web 站点。那么,你如何确保你访问的网站确实是你想访问的网站?(这话有点绕口令)
有些天真的同学会说:通过看网址里面的域名,来确保。为啥说这样的同学是“天真的”?因为 DNS 系统本身是不可靠的(尤其是在设计 SSL 的那个年代,连 DNSSEC 都还没发明)。由于 DNS 的不可靠(存在“域名欺骗”和“域名劫持”),你看到的网址里面的域名【未必】是真实滴!
(不了解“域名欺骗”和“域名劫持”的同学,可以参见俺之前写的《扫盲 DNS 原理,兼谈“域名劫持”和“域名欺骗/域名污染”》)
所以,HTTPS 协议必须有某种机制来确保“真实性”的需求(至于如何确保,后面会细聊)。

◇性能

再来说最后一个需求——性能。
引入 HTTPS 之后,【不能】导致性能变得太差。否则的话,谁还愿意用?
为了确保性能,SSL 的设计者至少要考虑如下几点:
1. 如何选择加密算法(“对称”or“非对称”)?
2. 如何兼顾 HTTP 采用的“短连接”TCP 方式?
(SSL 是在1995年之前开始设计的,那时候的 HTTP 版本还是 1.0,默认使用的是“短连接”的 TCP 方式——默认不启用 Keep-Alive)

◇小结

以上就是设计 SSL 协议时,必须兼顾的各种需求。后面聊协议的实现时,俺会拿 SSL 协议的特点跟前面的需求作对照。看看这些需求是如何一一满足滴。

★设计 HTTPS 协议的主要难点

设计 HTTPS 这个协议,有好几个难点。俺个人认为最大的难点在于“密钥交换”。
在传统的密码学场景中,假如张三要跟李四建立一个加密通讯的渠道,双方事先要约定好使用哪种加密算法?同时也要约定好使用的密钥是啥?在这个场景中,加密算法的【类型】让旁人知道,没太大关系。但是密钥【千万不能】让旁人知道。一旦旁人知道了密钥,自然就可以破解通讯的密文,得到明文。
好,现在回到 HTTPS 的场景。
当你访问某个公网的网站,你的浏览器和网站的服务器之间,如果要建立加密通讯,必然要商量好双方使用啥算法,啥密钥。——在网络通讯术语中,这个过程称之为“握手/handshake”。在握手阶段,因为加密方式还没有协商好,所以握手阶段的通讯必定是【明文】滴!既然是明文,自然有可能被第三方偷窥到。然后,还要考虑到双方之间隔着一个互联网,什么样的偷窥都可能发生。
因此,在握手的过程中,如何做到安全地交换密钥信息,而不让周围的第三方看到。这就是设计 HTTPS 最大的难点。

★结尾

本文费这么多口水,来介绍 HTTPS 的“需求”和“难点”,为啥捏?因为只有当你了解这些,后面介绍 SSL/TLS 的实现原理时,你才能理解——当初为啥要把协议设计成这个样子。

五、https基本运行过程

1)利用对称加密算法来加密网页内容,那么如何保证对称加密算法的秘钥的安全呢?

2)使用非对称加密算法来获得对称加密算法的秘钥,从而保证了对称加密算法的秘钥的安全,也就保证了对称加密算法的安全。

这里这样安排使用的原理是,利用了对称加密算法和非对称加密算法优点,而避免了它们的缺点。利用了对称加密算法速度快,而非对称加密算法安全的优点;同时巧妙的避免了对称加密算法的不安全性,以及需要同步密钥的缺点,也避免了非对称加密算法的速度慢的缺点。实在是巧妙了。

这里有两个问题:

(1)如何保证非对称加密算法公钥不被篡改?

解决方法:将公钥放在数字证书中。只要证书是可信的,公钥就是可信的。

(2)公钥加密计算量太大,如何减少耗用的时间?

解决方法:每一次对话(session),客户端和服务器端都生成一个”对话密钥”(session key),用它来加密信息。由于”对话密钥”是对称加密算法,所以运算速度非常快,而服务器公钥只用于加密”对话密钥”本身,这样就减少了加密运算的消耗时间。(也就是网页内容的加密使用的是对称加密算法)

因此,SSL/TLS协议的基本过程是这样的:
(1) 客户端向服务器端索要并验证非对称加密算法的公钥。
(2) 双方协商生成对称加密算法的”对话密钥”。
(3) 双方采用对称加密算法和它的”对话密钥”进行加密通信。
上面过程的前两步,又称为”握手阶段”(handshake)。

大白话说明一下:

第一步,爱丽丝给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。

第二步,鲍勃确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。

第三步,爱丽丝确认数字证书有效,然后生成一个新的随机数(Premaster secret),并使用数字证书中的公钥,加密这个随机数,发给鲍勃。

第四步,鲍勃使用自己的私钥,获取爱丽丝发来的随机数(即Premaster secret)。

第五步,爱丽丝和鲍勃根据约定的加密方法,使用前面的三个随机数,生成”对话密钥”(session key),用来加密接下来的整个对话过程。

六、https握手阶段详解

“握手阶段”涉及四次通信:

1) 客户端发出请求(ClientHello)

首先,客户端(通常是浏览器)先向服务器发出加密通信的请求,这被叫做ClientHello请求。在这一步,客户端主要向服务器提供以下信息:

(1)浏览器支持的SSL/TLS协议版本,比如TLS 1.0版。

(2)一个浏览器客户端生成的随机数,稍后用于生成对称加密算法的"对话密钥"。

(3)浏览器支持的各种加密方法,对称的,非对称的,HASH算法。比如RSA非对称加密算法,DES对称加密算法,SHA-1 hash算法。

(4)浏览器支持的压缩方法。

这里需要注意的是,客户端发送的信息之中不包括服务器的域名。也就是说,理论上服务器只能包含一个网站,否则会分不清应该向客户端提供哪一个网站的数字证书。
这就是为什么通常一台服务器只能有一张数字证书的原因。
对于虚拟主机的用户来说,这当然很不方便。2006年,TLS协议加入了一个Server Name Indication扩展[ 即 SNI 扩展],允许客户端向服务器提供它所请求的域名。

2) 服务器回应(SeverHello)

服务器收到客户端请求后,向客户端发出回应,这叫做SeverHello。服务器的回应包含以下内容:

(1)确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。

(2)一个服务器生成的随机数,稍后用于生成"对话密钥"。

(3)确认使用的加密方法,比如RSA公钥加密。

(4)服务器证书。

除了上面这些信息,如果服务器需要确认客户端的身份,就会再包含一项请求,要求客户端提供”客户端证书”。比如,金融机构往往只允许认证客户连入自己的网络,就会向正式客户提供USB密钥【俗称K宝】,里面就包含了一张客户端证书。

3) 客户端回应

客户端收到服务器回应以后,首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。

如果证书没有问题,客户端就会从证书中取出服务器的非对称加密算法的公钥。然后,向服务器发送下面三项信息。

(1)一个随机数。该随机数用服务器公钥加密,防止被窃听。

(2)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。

(3)客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验。

上面第一项的随机数,是整个握手阶段出现的第三个随机数,又称”pre-master key”。有了它以后,客户端和服务器就同时有了三个随机数,接着双方就用事先商定的加密方法,各自生成本次会话所用的同一把”会话密钥”。

至于为什么一定要用三个随机数,来生成”会话密钥”,dog250解释得很好:

“不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么pre master secret就有可能被猜出来,那么仅适用pre master secret作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。”

此外,如果前一步,服务器要求客户端证书,客户端会在这一步发送证书及相关信息。

4) 服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后,计算生成本次会话所用的对称加密算法的”会话密钥”。然后,向客户端最后发送下面信息。

(1)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。

(2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供客户端校验。

至此,整个握手阶段全部结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的HTTP协议,只不过用”会话密钥”加密内容。

七、session的恢复

握手阶段用来建立SSL连接。如果出于某种原因,对话中断,就需要重新握手。

这时有两种方法可以恢复原来的session:

一种叫做session ID:

session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的”对话密钥”,而不必重新生成一把。

客户端给出session ID,服务器确认该编号存在,双方就不再进行握手阶段剩余的步骤,而直接用已有的对话密钥进行加密通信。

另一种叫做session ticket:

session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。

客户端不再发送session ID,而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的,只有服务器才能解密,其中包括本次对话的主要信息,比如对话密钥和加密方法。当服务器收到session ticket以后,解密后就不必重新生成对话密钥了。

八、其他补充

8.1 请考虑介绍下常用于SPDY的HTTPS falst start握手,它比标准的握手少一个“server finished”的步骤。经过debug测试,发现SPDY+HTTPS false start握手确实比标准的SSL/TLS少一次握手,最后一次服务器到客户端的握手是没有的,第一次Finished后就可以传输数据了。

8.2 第三个随机数客户端是用公钥加密的然后在发送给服务端,服务端用私钥解密获取随机数。客户端和服务端用约定加密方法使用三个随机数生成对话密钥。

8.3 整个握手阶段都不加密(也没法加密),都是明文的。因此,如果有人窃听通信,他可以知道双方选择的加密方法,以及三个随机数中的两个。整个通话的安全,只取决于第三个随机数(Premaster secret)能不能被破解。

虽然理论上,只要服务器的公钥足够长(比如2048位),那么Premaster secret可以保证不被破解。但是为了足够安全,我们可以考虑把握手阶段的算法从默认的RSA算法,改为 Diffie-Hellman算法(简称DH算法)。

采用DH算法后,Premaster secret不需要传递,双方只要交换各自的参数,就可以算出这个随机数。

九、总结

本文如果结合 HTTPS连接的前几毫秒发生了什么 一起来理解HTTPS,将理解的更加深入。

1)HTTPS 结合使用了 非对称加密算法,对称加密算法,hash算法,分别利用他们的优势,避免他们的缺点。利用非对称加密算法获得对称加密算法的秘钥,保证他的安全性;然后实际的网页内容的加密使用的是对称加密算法,利用了对称加密算法速度快的优势,hash算法主要是防止篡改的发生,是一种校验机制,最后数字证书,保证了服务器在将非对称加密算法的公钥传给浏览器时的安全性(不会被中间人篡改),同时也标志了服务器的身份

2)HTTPS的四大金刚:

非对称加密算法(对称加密算法的秘钥) + 对称加密算法(加密内容) + 数字证书(防止篡改非对称加密算法的公钥) + HASH算法(防止篡改消息)== HTTPS

3)HTTPS的本质是什么?

HTTPS的本质就是在HTTP连接发起之前,先使用SSL/TLS协议,协调客户端和服务端,在两端各自生产一个对称加密算法的秘钥,然后使用普通的HTTP协议传输 经过对称加密算法加密的网页内容。因为对称加密算法的秘钥是安全的,所以对称加密算法加密的网页内容也是安全的。

 


参考:

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

https://www.cnblogs.com/digdeep/p/4832885.html

http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

https://program-think.blogspot.com/2014/11/https-ssl-tls-1.html

 

密码和证书-CloudFlare Along with Let’s Encrypt

如何在cloudflare 上更新 leti‘s encrypt  的SSL 证书问题?

因为 用tls 1.0更新 ssl 证书,不能通过 cdn 代理,所以不能用了。直接用cloudflare 的ssl就行。

I Have Cloudflare activated in my site to hide the real IP of the VPS. In Addition to that I’ve also installed cloudflare apache mod so that I get correct IP addresses of my site visitors.

So, now., when trying to renew the certificate it is giving me errors., I can’t renew before disabling CloudFlare so the IP turns to the real one., and I really think this is not possible to maintain it every 3 months,

Is there any fix for the problem ?

OK, so you’re using the tls-sni-01 challenge to verify your domain. That isn’t going to work with CloudFlare active.

The best solution, IMHO, is to use the webroot challenge. That challenge works with a single file, which will pass through CloudFlares CDN services.


For the basic CloudFlare plans, there isn’t a way to import your own certificate, so you won’t be able to use a Let’s Encrypt certificate on the publicly-visible CloudFlare service, unless you pay for a plan that supports this option.

Many CloudFlare users won’t even benefit from a Let’s Encrypt certificate, because CloudFlare can give you its own certificate for use with your origin server (the server that you run that CloudFlare is proxying for). CloudFlare will accept that CloudFlare-issued certificate for HTTPS connections between its CDN service and your origin server, and it will issue its own publicly-trusted certificate for HTTPS connections between end-users and the CDN service.

If you do want to get a Let’s Encrypt certificate for the origin server, even though there might not be much of a reason to do so, you should note that the TLS-SNI-01 verification method doesn’t work if the Let’s Encrypt CA isn’t connecting directly to the origin service (which is true if you have CloudFlare in front of your site when you get the certificate!). Other verification methods, HTTP-01 and DNS-01, will work in this case by letting you post files on your site or update DNS records for your site.

来自:https://community.letsencrypt.org/t/how-to-use-cloudflare-along-with-lets-encrypt/29221

密码和证书-网页中常见的asc、sha1等文件的含义

在下载软件时,我们常常会看到

Checksums
校验和是冗余校验的一种形式。 它是通过错误检测方法,对经过空间或时间所传送数据的完整性进行检查的一种简单方法。 计算机领域常见的校验和的方法有循环冗余校验、MD5、SHA家族等。

Signature
asc 是签名文件,随着科技的发展,文件数字化了,签名也有了数字签名。与传统的签名相比,数字的签名虽然复杂,却在防止篡改,防止假冒签名,防止签名者抵赖方面更有效。在中国,数字签名是具法律效力的。世界上其他国家和地区的状况不一。

密码和证书-https(ssl/tls)之证书的概述及获取和网站部署

一、CA证书概述

★先说一个通俗的例子

考虑到证书体系的相关知识比较枯燥、晦涩。俺先拿一个通俗的例子来说事儿。

◇普通的介绍信

想必大伙儿都听说过介绍信的例子吧?假设 A 公司的张三先生要到 B 公司去拜访,但是 B 公司的所有人都不认识他,他咋办捏?常用的办法是带公司开的一张介绍信,在信中说:兹有张三先生前往贵公司办理业务,请给予接洽……云云。然后在信上敲上A公司的公章。
张三先生到了 B 公司后,把介绍信递给 B 公司的前台李四小姐。李小姐一看介绍信上有 A 公司的公章,而且A公司是经常和 B 公司有业务往来的,这位李小姐就相信张先生不是歹人了。
说到这,爱抬杠的同学会问了:万一公章是伪造的,咋办捏?在此,俺要先声明,在本例子中,先假设公章是难以伪造滴,否则俺的故事没法说下去鸟。

◇引入中介机构的介绍信

好,回到刚才的话题。如果和 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 的介绍。

具体内容介绍:密码和证书-与证书相关的名称(SSL,X.509,PEM,DER,CRT,CER,KEY,CSR,P12等)

◇什么是CA?

CA 是“Certificate Authority”的缩写,也叫“证书授权中心”。(专业的解释看维基百科“这里”)
它是负责管理和签发证书的第三方机构,就好比例子里面的中介——C 公司。一般来说,CA 必须是所有行业和所有公众都信任的、认可的。因此它必须具有足够的权威性。就好比A、B两公司都必须信任 C 公司,才会找 C 公司作为公章的中介。

◇什么是CA证书?

CA 证书,顾名思义,就是CA颁发的证书。
前面已经说了,人人都可以找工具制作证书。但是你一个小破孩制作出来的证书是没啥用处的。因为你【不是】权威的 CA 机关,你自己搞的证书不具有权威性。
这就好比上述的例子里,某个坏人自己刻了一个公章,盖到介绍信上。但是别人一看,不是【受信任】的中介公司的公章,就不予理睬。坏蛋的阴谋就不能得逞啦。
文本后续提及的证书,若无特殊说明,均指 CA 证书。

◇什么是证书之间的信任关系?

在俺的例子里谈到,引入中介后,业务员要同时带两个介绍信。第一个介绍信包含了两个公章,并注明,公章C信任公章A。证书间的信任关系,就和这个类似。就是用一个证书来证明另一个证书是真实可信滴。

◇什么是证书信任链?

实际上,证书之间的信任关系,是可以嵌套的。比如,C 信任 A1,A1 信任 A2,A2 信任 A3……这个叫做证书的信任链。只要你信任链上的头一个证书,那后续的证书,都是可以信任滴。

◇什么是根证书?

“根证书”的洋文叫“root certificate”,专业的解释请看维基百科“这里”。为了说清楚根证书是咋回事,再来看个稍微复杂点的例子。
假设 C 证书信任 A 和 B;然后 A 信任 A1 和 A2;B 信任 B1 和 B2。则它们之间,构成如下的一个树形关系(一个倒立的树)。


处于最顶上的树根位置的那个证书,就是“根证书”。除了根证书,其它证书都要依靠上一级的证书,来证明自己。那谁来证明“根证书”可靠捏?实际上,根证书自己证明自己是可靠滴(或者换句话说,根证书是不需要被证明滴)。

二、证书有啥用?

◇验证网站是否可信(针对HTTPS)

通常,我们如果访问某些敏感的网页(比如用户登录的页面),其协议都会使用 HTTPS 而不是 HTTP。因为 HTTP 协议是明文的,一旦有坏人在偷窥你的网络通讯,他/她就可以看到网络通讯的内容(比如你的密码、银行帐号、等);而 HTTPS 是加密的协议,可以保证你的传输过程中,坏蛋无法偷窥。
但是,千万【不要】以为,HTTPS 协议有了加密,就可高枕无忧了。俺再举一个例子来说明,光有加密是不够滴。假设有一个坏人,搞了一个假的网银的站点,然后诱骗你上这个站点。假设你又比较单纯,一不留神,就把你的帐号,口令都输入进去了。那这个坏蛋的阴谋就得逞鸟。
为了防止坏人这么干,HTTPS 协议除了有加密的机制,还有一套证书的机制。通过证书来确保,某个站点确实就是某个站点。
有了证书之后,当你的浏览器在访问某个 HTTPS 网站时,会验证该站点上的 CA 证书(类似于验证介绍信的公章)。如果浏览器发现该证书没有问题(证书被某个根证书信任、证书上绑定的域名和该网站的域名一致、证书没有过期),那么页面就直接打开;否则的话,浏览器会给出一个警告,告诉你该网站的证书存在某某问题,是否继续访问该站点?为了形象起见,下面给出chrome 的截图。大多数知名的网站,如果用了 HTTPS 协议,其证书都是可信的(也就不会出现上述警告)。所以,今后你如果上某个知名网站,发现浏览器跳出上述警告,你就要小心啦!

◇验证某文件是否可信(是否被篡改)

证书除了可以用来验证某个网站,还可以用来验证某个文件是否被篡改。

基本原理:具体内容可看链接 密码和证书-数字签名概述及与数字证书的关系

1、用数字证书 保存  软件发布作者的公钥【证明这个公钥是软件发布作者的】

2、用将文件进行摘要算法(如hash函数),获取摘要,并用私钥加密。【这个就是数字签名】

3、将数字证书和 文件【文件附带了数字签名】一起发给用户,让用户检测软件安全性。

总结:用数字证书获得真正的公钥,提权数字签名中的摘要并将其和文件进行比较,判断文件是否修改过。


二、证书的获取

◇自签名证书

下面的操作可以看出:服务器私钥  server.key ,证书是  server.crt 【自签名证书,楼主没有亲自尝试过,仅做参考】

1.创建服务器证书密钥文件 server.key:
openssl genrsa -des3 -out server.key 1024
输入密码,确认密码,自己随便定义,但是要记住,后面会用到。
2.创建服务器证书的申请文件 server.csr
openssl req -new -key server.key -out server.csr
输出内容为:
Enter pass phrase for root.key: ← 输入前面创建的密码 
Country Name (2 letter code) [AU]:CN ← 国家代号,中国输入CN 
State or Province Name (full name) [Some-State]:BeiJing ← 省的全名,拼音 
Locality Name (eg, city) []:BeiJing ← 市的全名,拼音 
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany Corp. ← 公司英文名 
Organizational Unit Name (eg, section) []: ← 可以不输入 
Common Name (eg, YOUR name) []: ← 此时不输入 
Email Address []:[email protected] ← 电子邮箱,可随意填
Please enter the following ‘extra’ attributes 
to be sent with your certificate request 
A challenge password []: ← 可以不输入 
An optional company name []: ← 可以不输入
4.备份一份服务器密钥文件
cp server.key server.key.org
5.去除文件口令
openssl rsa -in server.key.org -out server.key
6.生成证书文件server.crt
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

◇CA机构申请证书

实际需要在自己网站上实现https的,可以用免费的https://letsencrypt.org/
对网站https://letsencrypt.org的功能重新封装的网站 https://www.sslforfree.com/

证书申请网站,会要求验证域名所有者是否是你本人。
要三种方法,建议选择 dns验证 比较简单。

一般情况下:从ca机构获取的证书,会有三个文件。

第一个是证书文件,里面有公钥。
第二个是私钥。
第三个是证书组文件,因为公钥是由中间机构签发的,一些浏览器可能不能识别,所以证书组就是为了证明从根证书到中间签发机构都是可信的。

### 在一些服务器 证书配置文件中,我们可以看到 以下配置
SSLCertificateFile /etc/ssl/example_com.crt
SSLCertificateKeyFile /etc/ssl/private/example_com.key
SSLCertificateChainFile /etc/ssl/example_com.ca-bundle

在nginx服务器配置文件中:只有ssl_certificate和 ssl_certificate_key 。如果一些浏览器不能识别单独的证书文件,那么需要将证书文件和证书组文件,组合在一起,生成一个证书链文件。最后将 ssl_certificate 配置成证书链文件。

合并证书链操作如下:

cat example_com.crt example_com.ca-bundle > example_com.chained.crt

记得一定要先将证书放在前面,然后将证书组放在后面。这样才能解析成功。
但是在实际生成过程中:证书链生成的还是有问题。实际用cat生成时,中间的

-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

###  会合并成一行
-----END CERTIFICATE----------BEGIN CERTIFICATE-----

###  特别注意:切分的时候,每一行的格式都是统一的,前面都是 -----  五个破折号

下面举例,正确的证书链文件内容:

-----BEGIN CERTIFICATE-----
MIIFbDCCBFSgAwIBAgISA5WD5KQw2Su8QWrrv6G5nlVfMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODExMjMxMDAwMjdaFw0x
OTAyMjExMDAwMjdaMB0xGzAZBgNVBAMTEnd3dy5odWFpaml1amlhLmNvbTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPB7xpQSEdD5ZvYU80fBiWaTRHa4
p1ONueojFD6NabMRMw2ct4PLHsiIt8z5hGF02JhKb/ZxLIIBh5dtqFxAy4OcYRWa
J+7Qi+1tgD695t0JkqsW/KGbbZtZRFHikhx4TTLyd5IWuEKjJA87+8ufgCv/zuEM
hpdqNs5YhjqrVNjLo5yIIwVWF4FRs3rkSqUthaw6bF3+ER5Cnlrmy4nM6t811KuS
aFAFU9ZpfxzbtFefVNZGn79CxMf9huvHUklJTZeUmtr8SkfRLSC8yclP2vW4l70G
EiT1UK7jPb+/x2qynnDMv+/EfYk3oJq1emTg1UNizLmKPAItWDhI50BGKa8CAwEA
AaOCAncwggJzMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUCG4SDRTDi0shGxdi/x7S
ZFrxaSswHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl7/Oo7KEwbwYIKwYBBQUH
AQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5pbnQteDMubGV0c2VuY3J5
cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5pbnQteDMubGV0c2VuY3J5
cHQub3JnLzAtBgNVHREEJjAkgg5odWFpaml1amlhLmNvbYISd3d3Lmh1YWlqaXVq
aWEuY29tMEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYI
KwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBBAYKKwYBBAHW
eQIEAgSB9QSB8gDwAHYAdH7agzGtMxCRIZzOJU9CcMK//V5CIAjGNzV55hB7zFYA
AAFnQDpiswAABAMARzBFAiEAyP9RowhmAeFy0FIw864vexsfEi7+I8eXXgRBgdma
lXACIFuyRLDwlDSymNcSibTq/RJt4AlYtVAs2zA9lOUOGwN4AHYAY/Lbzeg7zCzP
C3KEJ1drM6SNYXePvXWmOLHHaFRL2I0AAAFnQDpiuAAABAMARzBFAiEAtLhwBegO
6Hvo3lTzkb1OBW1pmI00QMalMyyp7a8l3DICICdx6IzPP8Q9Aj5nwHXr7TZId+ye
pT2ApN87VE74fiT8MA0GCSqGSIb3DQEBCwUAA4IBAQBJZ0dI9Uq8WzRagYaRZI3p
BelzOZ0ImRW3iipi/XBHFB3hXbEIMBvaPlzduZzYe70WRYJFkHTCdVWrUqhUuEv9
B0Q5ovW9KDcrDJVw7C9Y4UbpfDnq6NBxXXRr3azNUahCoYIVvTTNcfFiWXvhW2Ie
Yw3v1dfH4pxdeZodBInaikJ1o2IAYWXQVRuX06ywcItFIcH9aUuvP8g0DEEe3xwf
iIV3IJ+rUzEHLh/r+9CabSotT5TqwvYPLWnhBUD3YaD56VXGlipdZ7bQiH80CUXw
WvmDH84qEJ+D7btxFBYl+OP7irl3cdcQNmYYJOQWyMOK0h+AhSEBx7qpDOC/Ew1b
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----

三、网站部署https

nginx配置文件-安全配置-https(ssl/tls)和http2的配置

参考

https://www.namecheap.com/support/knowledgebase/article.aspx/9423//installing-a-ssl-certificate-on-apache

http://www.cnblogs.com/jingxiaoniu/p/6745254.html

https://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

密码和证书-Https与OpenSSL的关系及证书是否信任关系

HTTPS是一种协议,等于HTTP+TLS(由于历史原因,SSL3.0之后就被TLS1.0替代了)。

openssl是一套开源工具集,主要有两个特性:
1、实现了ssl2,ssl3,TLSv1,TLSv1.1,TLSv1.2协议。
2、实现目前常用的加密算法。

没有一个非常精准的方法来判断HTTPS是否使用openssl,但是根据网站返回的server类型,可以大致估计是否使用了openssl,比如如果使用apache或者nginx,那么肯定是使用了openssl。保守估计至少70%以上的网站是使用openssl的。而windows系列的服务器包括IIS,windows server等都是使用schannel,没有使用openssl,不会受heartbleed影响。

大白话:openssl就是用来创建证书密钥的工具。网站加了证书就可以实现https访问了。但是自己用openssl签发证书,是不会被浏览器信任的。权威的CA证书签发机构可以用openssl创建证书,并且被浏览器信任。

如下图,提示有风险,正常吗?是我哪里弄错了,还是一定要从某些机构申请的才可以?不申请不可以吗?

一般出现这种情况有两种原因:
1.证书签发机构,不是权威的CA证书签发机构,你目前的情况就属于这种情况
2.证书签发机构或者是该机构签发的部分证书在某些浏览器上是不受信任的,如wosign的部分证书在chrome浏览器上就会被打红叉