https:
https(Secure Hypertext Transfer Protocol) 安全超文本传输协议 它是以安全为目标的http通道，即它是http的安全版。它使用安全套接字层(SSL)进行信息交换。它在使用之前须要先得到证书。 它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作。并返回网络上传送回的结果。HTTPS实际上应用了Netscape的安全套接字层(SSL)作为HTTP应用层的子层。(HTTPS使用port443)SSL使 用40 位keyword作为RC4流加密算法，这对于商业信息的加密是合适的也更加安全。
https和http的差别：
https协议须要申请证书。http超文本传输协议，信息是明文传输。http则是具有安全性的ssl加密传输协议 。在port的使用中http通常是80,而https则是使用443port。
http的连接非常easy,是无状态的。而 https协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全 https解决的问题：
1 . 信任主机的问题. 採用https 的server 必须从CA 申请一个用于证明server用途类型的证书. 改证书仅仅实用于相应的server 的时候,客户度才信任次主机. 所以眼下全部的银行系统站点,关键部分应用都是https 的. 客户通过信任该证书,从而信任了该主机. 事实上这样做效率非常低,可是银行更側重安全. 这一点对我们没有不论什么意义,我们的server ,採用的证书无论自己issue 还是从公众的地方issue, client都是自己人,所以我们也就肯定信任该server.
2 . 防止通讯过程中的数据的泄密和被窜改
一般意义上的https, 就是 server 有一个证书.
a) 主要目的是保证server 就是他声称的server. 这个跟第一点一样.
b) 服务端和client之间的全部通讯,都是加密的. 1、详细讲,是client产生一个对称的密钥,通过server 的证书来交换密钥. 一般意义上的握手过程. 2、加下来全部的信息往来就都是加密的. 第三方即使截获,也没有不论什么意义.由于他没有密钥. 当然窜改也就没有什么意义了.
少许对client有要求的情况下,会要求client也必须有一个证书.
a) 这里client证书,事实上就相似表示个人信息的时候,除了username/password, 另一个CA 认证过的身份. 应为个人证书一般来说上别人无法模拟的,全部这样可以更深的确认自己的身份.
b) 眼下少数个人银行的专业版是这样的做法,详细证书可能是拿U盘作为一个备份的载体.像我用的交通银行的网上银行就是採取的这样的方式。
HTTPS 一定是繁琐的.
a) 本来简单的http协议,一个get一个response. 由于https 要还密钥和确认加密算法的须要.单握手就须要6/7 个往返. 不论什么应用中,过多的round trip 肯定影响性能.
https工作原理：
①client的浏览器向server传送clientSSL 协议的版本。加密算法的种类，产生的随机数，以及其它server和client之间通讯所须要的各种信息。
②server向client传送SSL 协议的版本，加密算法的种类，随机数以及其它相关信息，同一时候server还将向client传送自己的证书。
③客户利用server传过来的信息验证server的合法性，server的合法性包含：证书是否过期，发行server证书的CA 是否可靠，发行者证书的公钥是否能正确解开server证书的“发行者的数字签名”，server证书上的域名是否和server的实际域名相匹配。假设合法性验证没有通过，通讯将断开；假设合法性验证通过。将继续进行第四步。
④用户端随机产生一个用于后面通讯的“对称password”。然后用server的公钥（server的公钥从步骤②中的server的证书中获得）对其加密。然后传给server。
⑤server用私钥解密“对称password”(此处的公钥和私钥是相互关联的，公钥加密的数据仅仅能用私钥解密，私钥仅仅在server端保留。然后用其作为server和client的“通话password”加解密通讯。同一时候在SSL 通讯过程中还要完毕数据通讯的完整性。防止数据通讯中的不论什么变化。
⑥client向server端发出信息，指明后面的数据通讯将使用的步骤⑤中的主password为对称密钥，同一时候通知serverclient的握手过程结束。
⑦server向client发出信息，指明后面的数据通讯将使用的步骤⑤中的主password为对称密钥，同一时候通知clientserver端的握手过程结束。
⑧SSL 的握手部分结束。SSL 安全通道的数据通讯開始，客户和server開始使用同样的对称密钥进行数据通讯。同一时候进行通讯完整性的检验。
配置htps:
1、改动配置文件：
进入nginx配置文件/usr/local/lnmp/nginx/conf/ 下，打开nginx.conf
[root@localhost conf]# pwd
/usr/local/lnmp/nginx/conf
[root@localhost conf]# vim nginx.conf
配置该文件例如以下所看到的：
2、生成ssl数字证书：
进入/etc/pki/tls/，生成nginx.pem证书：
[root@localhost tls]# cd /etc/pki/tls/certs/
[root@localhost certs]# make nginx.pem
填写证书信息：
3、将nginx.pem文件复制到nginx配置文件里:
[root@localhost certs]# cp nginx.pem /usr/local/lnmp/nginx/conf/
4、将nginx命令载入到全局变量中
[root@localhost conf]# pwd
/usr/local/lnmp/nginx/conf
[root@localhost conf]# ln -s /usr/local/lnmp/nginx/sbin/nginx /usr/local/bin/
5、检測自己定义配置文件的完整路径是否，并又一次载入
[root@localhost conf]# nginx -t
nginx: the configuration file /usr/local/lnmp/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/lnmp/nginx/conf/nginx.conf test is successful
[root@localhost conf]# nginx -s reload
nginx: [error] invalid PID number “” in “/usr/local/lnmp/nginx/logs/nginx.pid”
在又一次载入时出现上述问题。提示没有可用的nginx.pid文件：
在使用的阿里云server上，进程性的 nginx -s stop后再次启动nginx -s reload ,总是会报错误，这应该是由于把nginx进程杀死后pid丢失了，下一次再开启nginx -s reload时无法启动
解决方法：
又一次执行/usr/local/lnmp/nginx/sbin/nginx:
[root@localhost conf]# /usr/local/lnmp/nginx/sbin/nginx
又一次启动：
[root@localhost conf]# /usr/local/lnmp/nginx/sbin/nginx -s reload
在重载nginx
[root@localhost conf]# nginx -s reload
成功。！
在index.html中写入显示nginx页面后欢迎语：
[root@localhost html]# pwd
/mnt/nginx-1.9.9/html
[root@localhost html]# echo “Hello, Welcome to Nginx!” > index.html
6、进入浏览器訪问訪问设置的nginx地址：https://192.168.3.169，点开I Understand the Risks点击Add Exception就可以:
点击comfire确认该认证。在訪问该nginx地址就行看到index.html中的欢迎语：
nginx下的https配置结束！