RHCE-https

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本传输安全协议）

是以安全为目标的HTTP通道。HTTPS并不是一个新协议，而是HTTP+SSL（TLS）。原本HTTP先和TCP（假定传输层是TCP协议）直接通信，而加了SSL后，就变成HTTP先和SSL通信，再由SSL和TCP通信，相当于SSL被嵌在了HTTP和TCP之间，使用端口号：443。

ssl 握手协议 ssL记录
SSL 是“Secure Sockets Layer”的缩写，中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。到了1999年，SSL 应用广泛，已经成为互联网上的事实标准。IETF 就把SSL 标准化。标准化之后SSL被改为 TLS（Transport Layer Security传输层安全协议）。
SSL协议分为两层：
SSL记录协议 （SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能。
SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
SSL协议提供的服务：
1）认证用户和服务器，确保数据发送到正确的客户机和服务器
2）加密数据以防止数据中途被窃取
3）维护数据的完整性，确保数据在传输过程中不被改变。
当你在浏览器的地址栏上输入https开头的网址后，浏览器和服务器之间会在接下来的几百毫秒内进行大量的通信。

数字签名
证书信息的合法性
（1）客户端浏览器向服务器端发送如下信息：
1、客户端支持的SSL /TLS协议的版本号。
2、Cipher Suite（密钥算法套件）。
3、客户端产生的随机数，稍后用于生成"对话密钥"。
（2）服务器端向客户端发送如下信息：
1、确认使用的加密通信协议版本，如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
2、确认使用的加密方法。
3、服务器证书。
证书：
对称秘钥---- 加密 解密
非对称秘钥-----公钥 （数据加密） 私钥（数据解密）
123
要使数字证书有用，它的结构必须采用一种可理解且可靠的形式，以便人们可以轻松地检索并理解证书内的信息。例如，护照采用这样一种结构：人们可以轻松地理解以前从未见过的那一类护照中的信息。同样，只要数字证书是标准化的，则无论颁发该证书的是哪个机构，人们都可以阅读并理解该证书。
S/MIME 标准规定：用于 S/MIME 的数字证书应遵守国际电信同盟 (ITU) X.509 标准。S/MIME 版本 3 明确要求数字证书应遵循 X.509 的第 3 版。由于 S/MIME 依赖于已建立的数字证书结构公认标准，因此 S/MIME 标准建立在该标准的发展之上，从而提高了它的认可度。
CA证书
X.509 标准规定数字证书应包含标准化信息。具体地说，X.509 版本 3 证书包含下列字段：
版本号： 证书所遵循的 X.509 标准的版本。
序列号 ：唯一标识证书且由证书颁发机构颁发的编号。
签名算法： CA用于对证书进行数字签名的hash算法。
证书签名：
颁发者名称 实际颁发该证书的证书颁发机构的标识。
有效期 数字证书保持有效的时间段，并包含起始日期和过期日期。
使用者名称 数字证书所有者的姓名。
使用者公钥信息 与数字证书所有者关联的公钥以及与该公钥关联的特定公钥算法。
颁发者唯一标识符 可以用来唯一标识数字证书颁发者的信息。
使用者唯一标识符 可以用来唯一标识数字证书所有者的信息。
扩充信息 与证书的使用和处理有关的其他信息。
证书颁发机构的数字签名 使用指纹算法中指定的HASH算法以及证书颁发机构的私钥进行加密的数字签名。
X.509通用的证书格式包含三个文件：key，csr，crt。
key是私钥文件。
csr是证书签名请求文件，用于提交给证书颁发机构（CA）对证书签名。
crt是由证书颁发机构（CA）签名后的证书，或者是开发者自签名的证书，包含证书持有人的信息，持有人的公钥，以及签署者的签名等信息。
4、服务器生成的随机数，稍后用于生成"对话密钥"。
（3）客户端利用服务器传过来的信息验证服务器的合法性。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，则可以知道认证服务器的公开密钥的是真实有效的数字证书认证机构，并且服务器的公开密钥是值得信赖的。（此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。）
（4）客户端随机产生一个用于后面通讯的对称密钥，然后用服务器的公钥对其加密，然后将加密后的对称密钥传给服务器。
HASH是把任意长度的输入（又叫做预映射pre-image）通过散列算法变换成固定长度的输出，该输出就是散列值。Hash算法特别的地方在于它是一种单向算法，用户可以通过hash算法对目标信息生成一段特定长度的唯一hash值，却不能通过这个hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。
常见的HASH算法：MD2、MD4、MD5、HAVAL、SHA、SHA-1、HMAC、HMAC-MD5、HMAC-SHA1。
共享密钥加密（对称密钥加密）：加密和解密使用相同密钥。
对称加密算法：DES、3DES、DESX、Blowfish、IDEA、RC4、RC5、RC6和AES。
公开密钥加密（非对称密钥加密）：公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，一把叫做公开密钥。私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。使用此加密方式，发送密文的一方使用公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听盗走。
常见的非对称加密算法：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）。
但由于公开密钥比共享密钥要慢，所以我们就需要综合一下他们两者的优缺点，使他们共同使用，而这也是HTTPS采用的加密方式。在交换密钥阶段使用公开密钥加密方式，之后建立通信交换报文阶段则使用共享密钥加密方式。
如何证明公开密钥本身是货真价实的公开密钥？如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输过程中，真正的公开密钥已经被攻击者替换掉了。这个时候就需要第三方公证单位来帮忙啦。
CA就是一个公认的公证单位，你可以自行产生一把密钥且制作出必要的证书数据并向CA单位注册，那么当客户端的浏览器在浏览时，该浏览器会主动向CA单位确认该证书是否为合法注册过，如果是，那么该次连接才会建立，如果不是，浏览器会发出警告信息，告知用户应避免建立连接。所以说，如此一来WWW服务器不但有公证单位的证书，用户在建立连接时也比较有保障。
HTTPS的安全通信机制：

工作流程可大致分为三个阶段：
认证服务器：浏览器内置一个受信任的CA机构列表，并保存了这些CA机构的证书。第一阶段服务器会提供经CA机构认证颁发的服务器证书，如果认证该服务器证书的CA机构，存在于浏览器的受信任CA机构列表中，并且服务器证书中的信息与当前正在访问的网站（域名等）一致，那么浏览器就认为服务端是可信的，并从服务器证书中取得服务器公钥，用于后续流程。否则，浏览器将提示用户，根据用户的选择，决定是否继续。当然，我们可以管理这个受信任CA机构列表，添加我们想要信任的CA机构，或者移除我们不信任的CA机构。
协商会话密钥：客户端在认证完服务器，获得服务器的公钥之后，利用该公钥与服务器进行加密通信，协商出两个会话密钥，分别是用于加密客户端往服务端发送数据的客户端会话密钥，用于加密服务端往客户端发送数据的服务端会话密钥。在已有服务器公钥，可以加密通讯的前提下，还要协商两个对称密钥的原因是因为非对称加密相对复杂度更高，在数据传输过程中，使用对称加密，可以节省计算资源。另外，会话密钥是随机生成，每次协商都会有不一样的结果，所以安全性也比较高。
加密通讯：此时客户端服务器双方都有了本次通讯的会话密钥，之后传输的所有Http数据，都通过会话密钥加密。这样网路上的其它用户，将很难窃取和篡改客户端和服务端之间传输的数据，从而保证了数据的私密性和完整性。
PKI（Public Key Infrastructure）公钥基础设施是提供公钥加密和数字签名服务的系统或平台，目的是为了管理密钥和证书。一个机构通过采用PKI 框架管理密钥和证书可以建立一个安全的网络环境。PKI 主要包括四个部分：X.509 格式的证书（X.509 V3）和证书废止列表CRL（X.509 V2）；CA 操作协议；CA 管理协议；CA 政策制定。
X.509通用的证书格式包含三个文件：.key，csr，crt。
key是私钥文件；
csr是证书签名请求文件，用于提交给证书颁发机构（CA）对证书签名；
crt是由证书颁发机构（CA）签名后的证书，或者是开发者自签名的证书，包含证书持有人的信息，持有人的公钥，以及签署者的签名等信息。

案例：搭建加密web服务 https-------httpd+mod_ssl
mod_ssl是一种以openssl 的工具箱为基础专门为apache webserver 提供密码保护的软件。

[root@localhost ~]# yum install mod_ssl -y
[root@localhost ~]# cd /etc/pki/tls/certs/
------------------------------------------------RHEL7-------------------------------------------------
  (第一种)       [root@localhost certs]# make jiami.crt
-------------------------------------------------------------------------------------
！！！！！！！注意！！！！！！！！！！！！！！！！
  (第二种) #openssl  req -newkey rsa:4096 -nodes -sha256 -keyout haha.key -x509 -days 365 -out haha.crt
----------------------------------------------x509 key  csr crt---------------------------------------
[root@www certs]# openssl genrsa -aes128 2048 > openlab.key
  (第三种) #openssl req -utf8 -new -key openlab.key -x509 -days 365 -out openlab.crt 
-------------------------------------------------------------------------------------
[root@localhost ~]# vim /etc/httpd/conf.d/vhosts.conf 
<VirtualHost 192.168.126.140:443>
•        SSLEngine on                开启ssL加密验证
•        SSLCertificateFile /etc/pki/tls/certs/openlab.crt指定证书路径
•        SSLCertificateKeyFile /etc/pki/tls/certs/openlab.key指定密钥文件路径
•        DocumentRoot /www/jiami
•        ServerName 192.168.126.140
</VirtualHost>
[root@localhost ~]# systemctl restart httpd

通过浏览器访问或者curl --insecure https://IP地址

https认证原理
一个HTTPS请求实际上包含了两次HTTP传输，如图：