Https 数字证书 数字签名
2016年05月17日 星期二, 发表于 北京
如果你对本文有任何的建议或者疑问, 可以在 这里给我提 Issues, 谢谢! :)
https概念、与http的区别
HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准(TCP)，用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效，使网络传输减少。
HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版,HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全;另一种就是确认网站的真实性。
``
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，于是网景公司 设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。
简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS和HTTP的区别主要如下：
-
https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
-
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
-
http和https使用的是完全不同的连接方式，用的默认端口也不一样，前者是80，后者是443。
-
http的连接很简单，是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
https加密解密验证过程
HTTPS加密、解密、及验证过程如下图：
整个过程：
1
2
3
4
5
6
7
8
1. 客户端向服务端发起请求
2. 服务端保存有自己的密钥对，于是将包含公钥的证书，返回给客户端
3. 客户端接收到服务器的证书后，验证是否是合法、正规的网站
4. 如果验证发现不合法，则展示警告
5. 如果合法，则客户端生成一个随机的对称密钥
6. 然后利用服务端的公钥对该随机对称密钥加密，并传输给服务器端
7. 服务器收到加密后的数据后，用自己的私钥解密得到该对称密钥
8. 之后，在服务器和客户端的交互过程中，所有的信息都是用该对称密钥加密后再传输的
那么，我们来看下这是如何保证之前我们提到的两点的：
- 安全的信息通道：因为传输的数据是加密过的，因此即使信息被截获，也是没用的
- 确认网站的真实性：因为涉及到对网站的证书的验证，因此可以保证真实性，至于验证过程是如何保证网站真实性的，可以看数字签名部分的介绍
数字证书是什么
在上面的https加密过程中，我们提到了证书，那么数字证书究竟是什么呢？
可以暂时把它理解为网站的身份证。这个身份证里包含了很多信息，其中就包含了上面提到的公钥。
它是由CA颁发给各网站的。而CA是证书颁发机构（Certificate Authority）。是负责发放和管理数字证书的权威机构
证书中的内容非常多，这里我们需要关注的有几个点：（完整的数字证书见最后）
-
证书包含了颁发证书的机构的名字 — CA
-
证书内容本身的数字签名（用CA私钥加密）
-
证书持有者的公钥
-
证书签名用到的hash算法
另外需要补充的一点是，每个CA都有自己的根证书，这个根证书相当于是每个CA自己的身份证，它没有别的证书对其认证，所以根证书都是自己验证自己，那我们怎么知道哪些根证书是合法的呢？其实每个浏览器都内置了一个根证书的列表，代表其认为合法的CA机构
那么，为什么数字证书就能保证网站的真实性呢？
我们来看以下两种证书伪造的情景：
- 完全伪造的证书
这种情况比较简单，对证书进行检查：
1
2
3
证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书
证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书
用CA的公钥，对伪造的证书的摘要进行解密，发现解不了。认为是危险证书
- 篡改过的证书
假设代理通过某种途径，拿到XX的证书，然后将证书的公钥偷偷修改成自己的，然后喜滋滋的认为用户要上钩了。然而太单纯了：
1
2
3
4
检查证书，根据CA名，找到对应的CA根证书，以及CA的公钥。
用CA的公钥，对证书的数字签名进行解密，得到对应的证书摘要AA
根据证书签名使用的hash算法，计算出当前证书的摘要BB
对比AA跟BB，发现不一致–> 判定是危险证书
数字签名是？与数字证书的区别是？
在上面我们提到了数字签名技术，那么这又是什么，它和数字证书有什么区别呢
数字签名、摘要是证书防伪非常关键的武器
简单的来说，“摘要”就是对传输的内容，通过hash算法计算出一段固定长度的串（是不是联想到了文章摘要）。然后，再通过私钥对这段摘要进行加密，加密后得到的结果就是“数字签名”。
1
明文 –> hash运算 –> 摘要 –> 私钥加密 –> 数字签名
我们知道https，使用数字证书，保证了数据传输通道的安全性、身份的真实性，但是它没法保证数据的完整性和数据发布的不可抵赖性。
数字签名有双重作用：
作用一就是保证数据的完整性，证明数据并非伪造，而且在传输的过程中没有被篡改
作用二就是防止数据的发布者否认其发布了该数据。
签名同时使用了非对称性加密算法和消息摘要算法，对一块数据签名时，会先对这块数据进行消息摘要运算生成一个摘要，然后对该摘要使用发布者的私钥进行加密。接收者接受这块数据后，先使用发布者的公钥进行解密得到原数据的摘要，再对接收到的数据计算摘要，如果两个摘要相同，则说明数据没有被篡改。同时，因为发布者 的私钥是不公开的，只要接收者通过发布者的公钥能成功对数据进行解密，就说明该数据一定来源于该发布者，他再怎么抵赖也没有用。
数字签名在数字证书验证过程中的作用
首先，我们需要知道，每个CA机构都有自己的一对公钥密钥
同时，我们在数字证书的内容中可以看到，包含了证书内容本身的数字签名信息，这个数字签名，就是利用CA的私钥对证书内容的摘要进行加密后的数据。
也正是因为了有了这部分数字签名，我们就可以保证，对网站的数字证书能正确验证是否合法了。（拿到证书后，利用ca公钥对证书中的数字签名解密得到散列值，再利用散列算法对内容进行散列，对比其是否一致就可以判断该证书是否合法了。）
如何申请数字证书
ssl证书申请的3个主要步骤
-
制作CSR文件
所谓CSR就是由申请人制作的Certificate Secure Request证书请求文件。制作过程中，系统会产生2个密钥，一个是公钥就是这个CSR文件，另外一个是私钥，存放在服务器上。要制作CSR文件，申请 人可以参考WEB SERVER的文档，一般APACHE等，使用OPENssl命令行来生成KEY+CSR2个文件，Tomcat，JBoss，Resin等使用 KEYTOOL来生成JKS和CSR文件，IIS通过向导建立一个挂起的请求和一个CSR文件。
-
CA认证
将CSR提交给CA，CA一般有2种认证方式：
1) 域名认证：一般通过对管理员邮箱认证的方式，这种方式认证速度快，但是签发的证书中没有企业的名称;
2) 企业文档认证：需要提供企业的营业执照。
也有需要同时认证以上2种方式的证书，叫EV ssl证书，这种证书可以使IE7以上的浏览器地址栏变成绿色，所以认证也最严格。
-
证书安装
在收到CA的证书后，可以将证书部署上服务器，一般APACHE文件直接将KEY+CER复制到文件上，然后修改httpD.CONF文 件;TOMCAT等，需要将CA签发的证书CER文件导入JKS文件后，复制上服务器，然后修改SERVER.XML;IIS需要处理挂起的请求，将 CER文件导入。
自签名数字证书
有的时候，我们提供一些web service，并不需要CA的认证，只是希望能通过https来对数据进行加密，这时候我们的服务端依然要提供一份证书，这时候我们就可以利用自签名数字证书。
以keytool为例（jdk自带），下面来说明如何产生自签名证书。
首先，执行如下命令
- genkeypair：代表开始生成一对密钥
- alias：指定生成的这个密钥对的别名
- keyalg：指定生成密钥对的加密算法，默认为dsa
- keystore：指定密钥库的存储文件路径，后缀名可以为.jks .keystore等等
输完指令后，会提示让你输入，名字、组织单位、组织、成熟、省市、国家，还需要提供密钥库密码和该对密钥的密码。
输完之后我们就建立了一个自签名的数字证书：
我们可以通过如下指令进行查看：
显示结果如下：
之所以这里是自签名，可以看到，我们的所有者和发布者都是同一个组织，因此叫自签名，如果我们将这个证书作为我们服务器的数字证书返回给浏览器，那么浏览器肯定会弹出警告窗，提示，这个证书无法验证其合法性。
当然我们可以选择将这个证书提交到CA去，来获得合法认证的证书，或者提交到自己的另一个证书去认证
具体过程可以参考：
http://www.cnblogs.com/youxia/p/java002.html
需要注意的一点：
在使用自签名数字证书的过程中，客户端在请求服务端时，容易报这样一个错：
java.security.cert.CertificateException: No name matching localhost found
这是因为，我们的客户端，在请求本地的服务时，目标地址，设置的是localhost，然而我们的服务端的自签名证书中的名字，即，在你新建证书时，输入的这个条目，一开始我输入的是一个名字，那么这种不对应，就导致了会报这种错。
所以，我们如果使用自签名，如果请求服务uri指定的是localhost或者其他域名，那么需要将证书的CN（Command Name）名字设置为localhost或域名，这样才能保证https正确连接。
但是，当我们需要调用另一台机器上的服务时，请求的URI肯定不是localhost，而是指定的IP地址，这种情况下，我们如果将server的自签名证书的cn设为它的ip地址，会报错：
SSLHandshakeException: No subject alternative names present
这是，因为，当我们以IP地址去请求服务时，返回的证书中必须包含 subject alternative names这个字段，但是因为我们的证书中没有，所以报错，因此在生成证书时，需要加上参数
1
-ext san=ip:xxx.xxx.xxx.xxx
这样，即使你的CN随便起，也是可以通过ip地址访问https服务了。
证书格式
-
证书版本号(Version) 版本号指明X.509证书的格式版本，现在的值可以为:
1) 0: v1
2) 1: v2
3) 2: v3
也为将来的版本进行了预定义
-
证书序列号(Serial Number)
序列号指定由CA分配给证书的唯一的”数字型标识符”。当证书被取消时，实际上是将此证书的序列号放入由CA签发的CRL中，
这也是序列号唯一的原因。
-
签名算法标识符(Signature Algorithm)
签名算法标识用来指定由CA签发证书时所使用的”签名算法”。算法标识符用来指定CA签发证书时所使用的:
1) 公开密钥算法
2) hash算法
example: sha256WithRSAEncryption
须向国际知名标准组织(如ISO)注册
-
签发机构名(Issuer)
此域用来标识签发证书的CA的X.500 DN(DN-Distinguished Name)名字。包括:
1) 国家(C)
2) 省市(ST)
3) 地区(L)
4) 组织机构(O)
5) 单位部门(OU)
6) 通用名(CN)
7) 邮箱地址
-
有效期(Validity)
指定证书的有效期，包括:
1) 证书开始生效的日期时间
2) 证书失效的日期和时间
每次使用证书时，需要检查证书是否在有效期内。
-
证书用户名(Subject)
指定证书持有者的X.500唯一名字。包括:
1) 国家(C)
2) 省市(ST)
3) 地区(L)
4) 组织机构(O)
5) 单位部门(OU)
6) 通用名(CN)
7) 邮箱地址
-
证书持有者公开密钥信息(Subject Public Key Info)
证书持有者公开密钥信息域包含两个重要信息:
1) 证书持有者的公开密钥的值
2) 公开密钥使用的算法标识符。此标识符包含公开密钥算法和hash算法。
-
扩展项(extension)
X.509 V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。标准扩展是指
由X.509 V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。
-
签发者唯一标识符(Issuer Unique Identifier)
签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串来唯一标识签发者的X.500名字。可选。
-
证书持有者唯一标识符(Subject Unique Identifier)
持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，用一比特字符串来唯一标识证书持有者的X.500名字。可选。
-
签名算法(Signature Algorithm)
证书签发机构对证书上述内容的签名算法
example: sha256WithRSAEncryption
-
签名值(Issuer’s Signature)
证书签发机构对证书上述内容的签名值