NGINX 配置 SSL 双向认证

对于 NGINX 的 HTTPS 配置，通常情况下我们只需要实现服务端认证就行，因为浏览器内置了一些受信任的证书颁发机构（CA），服务器端只需要拿到这些机构颁发的证书并配置好，浏览器会自己校验证书的可用性并通过 SSL 进行通讯加密。

网站建设哪家好，找创新互联！专注于网页设计、网站建设、微信开发、成都微信小程序、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了贵池免费建站欢迎大家使用！

但特殊情况下我们也需要对客户端进行验证，只有受信任的客户端才能使用服务接口，此时我们就需要启用双向认证来达到这个目的，只有 当客户端请求带了可用的证书才能调通服务端接口 。

CA 与自签名

CA 是权威机构才能做的，并且如果该机构达不到安全标准就会被浏览器厂商“封杀”，前不久的沃通、StartSSL 就被 Mozilla、Chrome 封杀了。不过这并不影响我们进行双向认证配置，因为我们是自建 CA 的..

为了方便，我们就在 NGINX 的目录下进行证书相关制作：

cd /etc/nginx

mkdir ssl

cd ssl

制作 CA 私钥

openssl genrsa -out ca.key 2048

制作 CA 根证书（公钥）

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

注意：

Common Name 可以随意填写

其他需要填写的信息为了避免有误，都填写 . 吧

服务器端证书

制作服务端私钥

openssl genrsa -out server.pem 1024

openssl rsa -in server.pem -out server.key

生成签发请求

openssl req -new -key server.pem -out server.csr

注意：

Common Name 得填写为访问服务时的域名，这里我们用 usb.dev 下面 NGINX 配置会用到

其他需要填写的信息为了避免有误，都填写 . 吧（为了和 CA 根证书匹配）

用 CA 签发

openssl x509 -req -sha256 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 -out server.crt

客户端证书

和服务端证书类似：

注意：

Common Name可以随意填写

其他需要填写的信息为了避免有误，都填写 . 吧（为了和 CA 根证书匹配）

至此需要的证书都弄好了，我们可以开始配置 NGINX 了。

其中 ssl_client_certificate /etc/nginx/ssl/ca.crt; 的意思是使用 CA 证书来验证请求带的客户端证书是否是该 CA 签发的。

配置好后就就重新加载 NGINX 吧：

service nginx reload

好了，下面我们可以开始验证了。

请求验证

验证过程可以选择在其他机器或是本机，为了能够解析 usb.dev，还需要配置一下 /etc/hosts：

127.0.0.1 usb.dev

如果用浏览器验证，需要把客户端证书导出成 p12 格式的，这里略过。我们重点是通过 curl 进行验证：

curl --insecure --key client.key --cert client.crt ' '

其中 --insecure 是忽略自建 CA 的非权威性。如果你验证正常那说明你运气好，因为这里有个 深坑：某些版本的 curl 会报错：

这些报错版本的 curl 居然要严格要求 --cert 实参的路径要完全正确，比如当前目录下面要用 --cert ./client.crt，用 --cert client.crt 是错误的。爬坑过程是启用了 -v 参数来观察完整的过程，发现其中有一条告警：

转自：

怎么验证nginx配置域名ssl证书成功

配置完成后重启服务器，然后用https访问来测试是否配置成功。Nginx配置SSL参考教材

nginx动态域名解析

原文链接：

接 上篇文章 中提到的 Nginx 解析域名地址的问题，用一句话描述就是“proxy_pass 中如果配置的是域名地址，Nginx 只有在 start / restart / reload 时，才会连接一次域名服务器解析域名，缓存解析的结果，后续则 不会根据解析结果的 TTL 进行自动更新 ”，如果遇到了域名地址配置有多个 IP ，且还在动态变化，那就会出现 Nginx 把请求转发到一个过期的 IP 地址的情况，连接超时的报错日志类似这样：

这个说法在 官方的一篇 2016 年的博客 中有提到：

除此之外，除了一些分析源码的网络文章，暂时还没有找到其他的官方文档中说到这个细节

在 upstream 中可以对上游的服务器进行更详细的设置，解决 DNS 缓存的问题可以在 upstream 中指定需要的负载均衡算法，比如 least_conn ，并指定 max_fails ，以实现调用失败 N 次之后判定该服务异常，暂停转发该服务

注：

这个配置的示例是官方博客中的，看到这个配置时觉得有点奇怪，自己进行了模拟测试，测试的方案是在 hosts 文件中配置一个模拟的域名与三个 IP 地址，其中两个 IP 是正确的，另一个是内网不存在的 IP，测试的结果就是 Nginx 始终会将请求转发到那个错误的 IP 去，日志中一直能看到超时的报错，配置的 max_fails 仿佛没有任何作用（有补充配置了 fail_timeout ，也尝试配置了 proxy_next_upstream 、 proxy_next_upstream_timeout 和 proxy_next_upstream_tries ）

不清楚用 hosts 配置的方式是不是必然会出现这样的情况，因为目前没条件测试真正想要的场景，所以不敢说博客中的这种配置是错的【如果以后碰巧有条件能测试验证，再回头来更新

最初学习 Nginx 的时候测试过 max_fails 这个配置，当时在 upstream 里配置的都是一些 IP 地址的上游服务。再次按 IP 地址进行测试，在 upstream 中配置两个正确的 IP 地址 和一个错误的 IP 地址，发现这样的配置就是能生效的，失败一定次数之后（实际失败的次数比设置的 max_fails 多，不清楚什么原因），Nginx 在 fail_timeout 时间内就不再转发请求到那个错误的 IP

resolver 的配置详情可看 官方文档 ，示例的配置是指定 DNS 服务器 10.0.0.2，指定 DNS 解析的有效时间为 10 秒，按博客 《Nginx动态解析upstream域名》 中博主的测试，不是说 Nginx 每过 10 秒会自己重新调一次 DNS 解析，而是有请求转发时才检验一次有效期是否过期

不配置 valid 选项时，V1.1.9 之后的 Nginx 默认会使用 DNS 解析结果中的 TTL

在 proxy_pass 中使用变量，带来的作用就是在 TTL 过期时能再次调用 DNS 解析，从而解决一直使用缓存结果的问题

这大概是目前官方原版唯一解决 DNS 缓存的解决方案了，带来的弊端也如 《Nginx动态解析upstream域名》 的博主所说，不能使用 upstream 模块特有的相关配置

Nginx Plus 版有更好的配置解决这些问题，另外使用 Lua 插件或许也能更完美的解决这个问题，暂时就没什么研究了

nginx 域名配置

Nginx 多域名配置 - Rickzhai - 博客园

首先打开nginx域名配置文件存放目录：/usr/local/nginx/conf/servers ，如要绑定域名 则在此目录建一个文件： 然后在此文件中写规则，如：

server{

listen 80;

server_name ; #绑定域名

index index.htm index.html index.php; #默认文件

root /home/www/itblood点抗 ; #网站根目录

include location.conf; #调用其他规则，也可去除

}

然后重起nginx服务器，域名就绑定成功了nginx服务器重起命令：/etc/init.d/nginx restart

新闻名称：nginx域名怎么验证 nginx配置域名访问到指定页面
地址分享：http://kswjz.com/article/ddehphc.html