Nginx rewrite 测试和SSL工作流程与nginx配置https方法以及源码安装nginx

最新推荐文章于 2024-09-11 17:00:24 发布

狂风中的戈仑少年

最新推荐文章于 2024-09-11 17:00:24 发布

阅读量181

点赞数

文章标签： nginx ssl https

本文链接：https://blog.csdn.net/weixin_62017198/article/details/133317074

版权

文章详细介绍了如何在Nginx配置中使用rewrite规则进行路径重定向，包括临时重定向和永久重定向的区别。此外，还涉及了如何配置HTTPS，包括自签名证书的生成和SSL工作流程的抓包分析。最后讲解了Nginx源码的安装步骤。

摘要由CSDN通过智能技术生成

rewrite测试

在nginx文件目录下的配置文件中添加该配置

   server{

    listen 4040;  #监听端口
    location / {   
    root /www/ip/129;   #html文件的存放目录
    index index.html;   #默认返回的html文件
    rewrite /test/test1/test2/(.*).html /$1.html; 
    #将/test/test1/test2/xxx.html路径转换为 html文件存放目录下的xxx.html
    }
}

这样访问/test/test1/test2/test.html 时就会访问存放目录下的test.html文件

访问/test/test1/test2/test1.html 时就会访问存放目录下的test1.html文件

访问/test/test1/test2/test2.html 时就会访问存放目录下的test2.html文件

flag:

redirect(临时重定向)：在rewrite /test/test1/test2/(.*).html /$1.html 后面添加redirect可以返回状态码为302的临时重定向响应报文。

permanent(永久重定向)：在rewrite /test/test1/test2/(.*).html /$1.html 后面添加permanent可以返回状态码为301的永久重定向响应报文。

nginx配置https

在nginx目录下创建一个cert文件夹cd进去

# 生成CA的私钥
openssl genrsa -out ca.key 2048
# 生成CA的公钥
openssl rsa -in ca.key -pubout -out ca.pub
# 生成CA的申请文件
openssl req -new -key ca.key -out ca.csr
# 生成CA的自签证书
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt -days 365

# 生成服务器端的私钥
openssl genrsa -out server.key 2048
# 生成服务器端的证书申请文件：
openssl req -new -key server.key -out server.csr

# 使用CA机构的ca.crt,以及ca.key为server.csr申请文件签发证书
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key 
-CAcreateserial -days 3650 -out server.crt

完成后cert文件夹中应有

之后在nginx配置文件中加入

server{
    listen 443 ssl;
    ssl_certificate cert/server.crt; #服务器的证书 也可以用绝对路径
    ssl_certificate_key cert/server.key; #服务器的私钥 也可以用绝对路径
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_protocols SSLv2 TLSv1 TLSv1.2;

    location / {
        root /www/https;
        index index.html;
    }
}

之后浏览器即可使用https协议访问服务器，因为这个证书是我们自签的所以浏览器不认，官方的数字证书要自己去申请。

SSL工作流程

我们对之前的https访问进行抓包，得到了以下几个包

SSL工作流程分为这几个部分：（*是可选的）

第一阶段：

Client Hello: browser -> server

传输自己的

tls的版本
随机数：random_client
加密套件：密钥交换算法(产生会话密钥的), 非对称加密的算法，对称加密的算法，散列算法(校验消息的完整性)
压缩算法:
扩展

第二阶段：

Server Hello: server -> browser

传输自己的

tls的版本
随机数：random_server
加密套件： Cipher Suite: Unknown (0xcca8)
压缩算法： null
扩展: 省略

certificate: server -> browser
服务器将自己的证书发送给browser

server key exchange： server-> browser
密钥交换的参数：公钥和签名

Certificate Request(可以省略)：server -> browser

服务器需要客户端来自验身份，客户端才会发送自己的certificate(证书)，一般不需要

server hello Done: server-> browser: 告知客户端，服务器这一阶段完成了

第三阶段：

certificate : browser->server（可以省略）
前提：在第二阶段如果有certificate request 包，客户端才会发送自己的certificate给服务器

client key exchange: browser-server
客户端密钥交换提供的参数：公钥(生成会话密钥要用)

change cipher spec: browser->server
编码改变通知：就是一条通知消息：客户端通知服务器：客户端后边发送的数据，要进行加密了

encypted handshake message: 加密握手消息：校验消息完整性

对之前所有发送的数据报进行hash(散列)：通知服务器，客户端在这一阶段完成了工作

第四阶段：

change cipher spec: 编码改变通知 server - client
通知客户端，后边的数据要进行加密了

enrypted handshake message: server - client
加密握手消息：即对之前客户端和服务器的消息进行加密：消息完整性校验

Application Data：加密的消息

注意：

在第一阶段的Client Hello中浏览器传递了一个随机数random_client

在第二阶段的Server Hello中服务器也传递了一个随机数random_server

且在第三阶段的client key exchange中浏览器传递了自己的公钥

此时这三个数客户端和服务器端都持有了，之后

客户端和服务器：各自使用加密算法(random_client,random_server,pre-master) 生成对称加密密钥： session_client_key == session_server_key

这个密钥便是之后客户端和服务器端进行会话时的对称加密密钥，

这样就保证了http报文的安全性，不再是明文传输了
注意：不会再网络中传输会话密钥的.