Nginx HTTPS配置详解
文章目录
- 一 、 HTTPS概述
-
- 1.1 什么是HTTPS
- 1.2 为何需要HTTPS
- 1.3 TLS如何实现加密
- 二、HTTPS实现原理
-
- 2.1 加密模型-对称加密
- 2.2 加密模型-非对称加密
- 2.3 身份验证机构-CA
- 2.4 HTTPS通讯原理
- 三、HTTPS扩展知识
-
- 3.1 https证书类型
- 3.2 Https购买建议
- 3.3 Https颜色标识
- 四、HTTPS单台配置实践
-
- 4.1 配置SSL语法
- 4.1 创建SSL证书
- 4.2 配置SSL场景
- 五、HTTPS集群配置实践
-
- 5.1 环境准备
- 5.2 配置应用节点
- 六、企业级HTTPS场景配置实践
-
- 6.1 模拟银行网站场景
- 6.2 匹配单域名走http协议
- 七、HTTPS优化配置实践
一 、 HTTPS概述
1.1 什么是HTTPS
- HTTPS安全的超文本传输协议，我们现在大部分站点都是通过HTTPS来实现站点数据安全。
- 早期网景公司设计了SSL（Secure Socket Layer）安全套接层协议，主要对HTTP协议传输的数据进行加密。那如何将站点变成安全的HTTPS站点呢？我们需要了解SSL（Secure Socket Layer）协议。
而现在很多时候我们使用的是TLS（Transport Layer Security）传输层安全协议来实现的加密与解密。
1.2 为何需要HTTPS
因为HTTP采用的是明文传输数据，那么在传输（账号密码、交易信息、等敏感数据）时不安全。容易遭到篡改，如果使用HTTPS协议，数据在传输过程中是加密的，能够有效避免网站传输时信息泄露。
1.3 TLS如何实现加密
TLS/SSL工作在OSI七层模型中，应用层与传输层之间。
1.提供数据安全：保证数据不会被泄露。
2.提供数据的完整性：保证数据在传输过程中不会被篡改。
3.对应用层交给传输层的数据进行加密与解密。
二、HTTPS实现原理
2.1 加密模型-对称加密
- 对称加密：两个想通讯的人持有相同的秘钥，进行加密与解密。如下：
- bob将原始文档通过秘钥加密生成一个密文文档。
- alice拿到这个密文文档以后，它可以用这把秘钥还原为原始的明文文档。
对称加密究竟是如何实现的，我们可以以RC4这样一个对称加密序列算法来看一下。 - 加密：秘钥序列+明文=密文
- 解密：秘钥序列+密文=明文
2.2 加密模型-非对称加密
非对称加密：它根据一个数学原理，创建一对秘钥（公钥和私钥）公钥加密，私钥解密；
- 私钥：私钥自己使用，不对外开放。
- 公钥：公钥给大家使用，对外开放。
- 比如：alice有一对公钥和私钥，他可以将公钥发布给任何人。假设Bob是其中一个，当Bob要传递一份加密文档给alice，那么Bob就可以用alice的公钥进行加密，alice收到密文文档后通过自己的私钥进行解密，获取原始文档。
注意：alice必须知道Bob就是Bob，也就是它收到的信息必须是Bob发来的，那么这个信任问题，在多方通讯的过程中，必须有一个公信机构来验证双方的身份，那么这个机构就是CA机构。
2.3 身份验证机构-CA
通讯双方是如何验证双方的身份？CA机构是可信任组织机构，主要用来颁发证书及验证证书。那CA机构又是如何申请和颁发证书的呢?
我们首先需要申请证书，需要进行登记，登记我是谁，我是什么组织，我想做什么，到了登记机构在通过CSR发给CA，CA中心通过后，CA中心会生成一对公钥和私钥，那么公钥会在CA证书链中保存，公钥和私钥证书订阅人拿到后，会将其部署在WEB服务器上
- 当浏览器访问我们的https站点时，它会去请求我们的证书
- Nginx会将我们的公钥证书回传给浏览器。
- 浏览器会去验证我们的证书是否是合法的、是否是有效的。
- CA机构会将过期的证书放置在CRL服务器，那么CRL服务的验证效率是非常差的，所以CA又推出了OCSP响应程序，OCSP响应程序可以查询指定的一个证书是否过期，所以浏览器可以直接查询OCSP响应程序，但OCSP响应程序性能还不是很高。
- Nginx会有一个OCSP的开关，当我们开启后，Nginx会主动上OCSP上查询，这样大量的客户端直接从Nginx获取，证书是否有效。
2.4 HTTPS通讯原理
HTTPS加密过程，HTTPS采用混合加密算法，即对称加密、和非对称加密。
通信前准备工作：申请域名对应的证书，并将其部署在Nginx服务器中。
- 第一步客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件和客户端支持TLS协议版本等信息。
- 服务端会向客户端发送 Server Hello 消息。返回自己的公钥证书、挑选一个合适的加密套件、另外还会生成一份随机数 Random2推送给客户端。至此客户端和服务端都拥有了两个随机数（Random1+ Random2）
- 客户端收到服务端传来的公钥证书后，先从 CA 验证该证书的合法性（CA公钥去解密公钥证书），验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密Random3。
- 服务端用自己的私钥解出客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边根据同样的算法生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。
三、HTTPS扩展知识
3.1 https证书类型
3.2 Https购买建议
保护1个域名www.bertwu.com
保护5个域名 (www images cdn test m).bertwu.com
通配符域名*.bertwu.com
3.3 Https颜色标识
- Https不支持续费,证书到期需重新申请新并进行替换。
- Https不支持三级域名解析，如 test.m.bertwu.net 、*.m.bertwu.net
- Https显示绿色，说明整个网站的url都是https的，并且都是安全的。
- Https显示黄色，说明网站代码中有部分URL地址是http不安全协议的。(https (http url) )
- Https显示红色，要么证书是假的，要么证书已经过期。
四、HTTPS单台配置实践
4.1 配置SSL语法
#官方示例
worker_processes auto;
http {
...
server {
listen 443 ssl;
keepalive_timeout 70;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # 协议
ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; # 加密套件
ssl_certificate /usr/local/nginx/conf/cert.pem; # 公钥证书存放路径
ssl_certificate_key /usr/local/nginx/conf/cert.key; # 私钥证书存放路径
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
...
}
}
4.1 创建SSL证书
1.创建证书存储目录
[root@web01 ~]# mkdir -p /etc/nginx/ssl_key
2.使用openssl命令充当CA权威机构创建证书（类似黑户）
[root@web01 ~]# cd /etc/nginx/ssl_key/
[root@web01 ssh_key]# openssl genrsa -idea -out server.key 2048
Generating RSA private key, 2048 bit long modulus
.........................+++
...............+++
e is 65537 (0x10001)
Enter pass phrase for server.key: #随便输入密码123456
Verifying - Enter pass phrase for server.key:
3.生成自签证书，同时去掉私钥的密码
[root@web01 ssl_key]# openssl req -days 36500 -x509 \
-sha256 -nodes -newkey rsa:2048 -keyout server.key -out server.crt
...
[root@web01 ssl_key]# ls
server.crt server.key
# req -->用于创建新的证书
# new -->表示创建的是新证书
# x509 -->表示定义证书的格式为标准格式
# key -->表示调用的私钥文件信息
# out -->表示输出证书文件信息
# days -->表示证书的有效期
4.2 配置SSL场景
如果用户忘记在浏览器地址栏输入 https:// 协议那么将不会跳转至https站点；所以监听http请求，跳转到https
[root@web01 conf.d]# cat s.bertwu.conf
server {
listen 443 ssl;
server_name s.bertwu.net;
root /code;
ssl_certificate ssl_key/server.crt;
ssl_certificate_key ssl_key/server.key;
location / {
index index.html;
}
}
# 如果http访问，重定向到https
server {
listen 80;
server_name s.bertwu.net;
return 302 https://$server_name$request_uri;
}
五、HTTPS集群配置实践
需求，将博客系统升级到https负载均衡轮询调度。
5.1 环境准备
| 主机名 | 外网IP(NAT) | 内网IP(LAN) | 角色 |
|---|---|---|---|
| lb01 | eth0:10.0.0.5 | eth1:172.16.1.5 | nginx-proxy |
| eb01 | eth0:10.0.0.7 | eth1:172.16.1.7 | nginx-web01 |
| web02 | eth0:10.0.0.8 | eth1:172.16.1.8 | nginx-web02 |
5.2 配置应用节点
1.nginx-proxy
[root@lb01 conf.d]# cat s.blog.conf
upstream blog {
server 10.0.0.7:80;
server 10.0.0.8:80;
}
server {
listen 443 ssl;
server_name blog.oldxu.net;
ssl_certificate ssl_key/6152893_blog.oldxu.net.pem;
ssl_certificate_key ssl_key/6152893_blog.oldxu.net.key;
location / {
proxy_pass http://blog;
include proxy_params;
}
}
# 用户使用http 直接跳转https
server {
listen 80;
server_name blog.bertwu.net;
return 302 https://$server_name$request_uri;
}
- nginx-web01配置
[root@web01 conf.d]# cat s.bertwu.conf
server {
listen 80;
server_name blog.oldxu.net;
root /code/wordpress;
location / {
index index.html index.php;
}
location ~* .*\.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param HTTP on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
- nginx-web02配置
[root@web02 conf.d]# cat s.bertwu.conf
server {
listen 80;
server_name blog.oldxu.net;
root /code/wordpress;
location / {
index index.html index.php;
}
location ~* .*\.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param HTTP on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
六、企业级HTTPS场景配置实践
6.1 模拟银行网站场景
1.用户访问网站主站，使用 http 协议提供访问，
2.当用户点击登陆时，则网站会跳转至一个新的域名，并使用的是 Https 提供安全访问。
[root@web01 conf.d]# cat yh.conf
server {
listen 443 ssl;
charset utf-8;
server_name login.bertwu.net;
root /code/login;
ssl_certificate ssl_key/server.crt;
ssl_certificate_key ssl_key/server.key;
location / {
index index.html;
}
}
server {
listen 80;
charset utf-8;
root /code;
server_name yh.bertwu.net;
location / {
index index.html;
}
location /login {
return 302 https://login.bertwu.net;
}
}
[root@web01 code]# cat /code/index.html
<p>欢迎来到xx建设银行</p>
<a href="/login">点我登录</a>
[root@web01 code]# cat /code/login/index.html
账号：<input type="text"></input>
密码：<input type="password">密码：</input>
<input type="submit" name="登录">
6.2 匹配单域名走http协议
希望用户访问网站的所有Url走Https协议，但访问s.bertwu.net/abc时走Http协议
[root@lb01 conf.d]# cat abc.conf
upstream aaa {
server 10.0.0.7:80;
server 10.0.0.8:80;
}
server {
listen 443 ssl;
server_name s.bertwu.net;
ssl_certificate ssl_key/server.pem;
ssl_certificate_key ssl_key/server.key;
location / {
proxy_pass http://aaa;
include proxy_params;
}
}
server {
listen 80;
server_name s.bertwu.net;
if ( $request_uri !~* "^/abc") {
return 302 https://$server_name$request_uri;
}
}
七、HTTPS优化配置实践
SSL的运行计算需要消耗额外的 CPU 资源，SSL通讯过程中『握手』阶段的运算最占用 CPU 资源，有如下几个方面可以进行调整与优化。
- 设置worker进程数设置为等于CPU处理器的核心数。worker_processes auto
- 启用 keepalive 长连接，一个连接发送更多个请求
- 启用 shared 会话缓存，所有worker工作进程之间共享的缓存，避免进行多次 SSL『握手』
- 禁用 builtin 内置的缓存，仅能供一个worker工作进程使用，使用shared缓存即禁止builtin
worker_processes auto;
http {
...
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on; #Nginx决定使用哪些协议与浏览器进行通讯
keepalive_timeout 70; #设置长连接
# 默认不开启session_cache： a握手后，关闭浏览器，再次访问，需要重新握手；
#建立握手后如果连接断开，在session_timeout时间内再次连接，无需再次建立握手，可直接复用之间缓存的连接。
ssl_session_cache shared:SSL:10m; #1M缓存空间能存储 4000 个会话数量
ssl_session_timeout 1440m; #配置会话超时时间 （ 默认5分钟 ）
}