博客博文目录

博文目录

Nginx 配置 Let's Encrypt TLS 证书

 

jnil 关注

2016.11.20 18:07* 字数 1102 阅读 1750评论 0喜欢 0

本文是我参考互联网上一些 HTTPS 相关文章, 而后自己实践而来
主要内容由 ** 获取证书 ,nginx TSL 配置 ** 两部分组成

项目环境搭建

• Git (安装 Git)
• Nginx (Nginx 安装配置)

获取证书

安装完 Git 后, 克隆 certbot(* 原名 letsencrypt*) 项目

$ git clone https://github.com/certbot/certbot
$ cd certbot

克隆完成后, 此时可以通过命令获取证书

• Webroot
  该方式适用于本机中正在运行中的项目, 无须停止服务器即可申请

$ ./certbot-auto certonly --webroot -w /usr/local/nginx/html --email admin@example.com -d example.com -d www.example.com -d other.example.com

--webroot 为申请方式类型
-w /usr/local/nginx/html 配置申请域名项目的 Webroot 跟路径, 以静态页面为例

location / {
    root   /usr/local/nginx/html;
    index  index.html;
}

该方式会在 /usr/local/nginx/html 目录下创建一个 .well-known/acme-challenge 文件夹, 然后生成一个随机文件进行访问. 如
http://example.com/.well-known/acme-challenge/HGr8U1IeTW4kY_Z6UIyaakzOkyQgPr_7ArlLgtZE8SX
如果项目进行了反向代理, 请确保 -w 参数后面路径为 代理项目所在的根目录
--email admin@example.com 为申请者的 ** 邮箱 **, 在证书快过期时, 会发送通知邮件
-d example.com 为要 ** 申请的域名 **, 允许存在多个, 格式为 -d 域名 -d 域名, ** 但要求域名访问地址为本机 **

• Standalone
  该方式需要 ** 确保 80,443 端口没有被占用 **

$ ./certbot-auto certonly --standalone --email admin@example.com -d example.com -d www.example.com -d other.example.com

--standalone 为申请方式类型
--email admin@example.com -d example.com 参数参考 Webroot 方式
如果验证没有问题, 稍候页面会弹出一个协议对话框, 点击 Agree 即可

• Manual
  该方式适用于申请证书服务器不是域名所在服务器的情况

$ ./certbot-auto certonly --manual --email admin@example.com -d example.com -d www.example.com -d other.example.com

--standalone 为申请方式类型
--email admin@example.com 参数参考 Webroot 方式
-d example.com 为需要申请的域名,需要拥有对该域名所在机器的读写权限
运行后, 会要求用户在域名所在服务器的项目跟目录创建一个文件, 并指定文件内容

Make sure your web server displays the following content at
http://example.com/.well-known/acme-challenge/VE_oSzihad5ZNYPnE_OLT2aQ-BdT_M3z5ITj53wQ-Oc before continuing:
VE_oSzihad5ZNYPnE_OLT2aQ-BdT_M3z5ITj53wQ-Oc.JhmxNt13DUzzmC4_7VfnfWh1gmePbExxQygAMf9KTSo
# 省略
# /tmp/certbot/public_html 应为域名所在服务器的项目跟路径
mkdir -p /tmp/certbot/public_html/.well-known/acme-challenge
# 进入项目跟路径
cd /tmp/certbot/public_html
# 指定内容输入到指定文件中
printf "%s" VE_oSzihad5ZNYPnE_OLT2aQ-BdT_M3z5ITj53wQ-Oc.JhmxNt13DUzzmC4_7VfnfWh1gmePbExxQygAMf9KTSo > .well-known/acme-challenge/VE_oSzihad5ZNYPnE_OLT2aQ-BdT_M3z5ITj53wQ-Oc
# 省略
Press Enter to Continue

操作完成后按下回车键即可

申请操作成功后, 会在界面中输出证书的存放路径, 以及证书的到期时间 (**90 天 **)

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/example.com/fullchain.pem. Your cert
   will expire on 2017-08-17. To obtain a new or tweaked version of
   this certificate in the future, simply run certbot-auto again. To
   non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

生成证书中会创建 /etc/letsencrypt 文件夹, 证书文件默认存放在 /etc/letsencrypt/live/example.com 文件夹中, 其中 example.com 取自第一个域名
在 example.com 文件夹中包含 4 个文件 cert.pem chain.pem fullchain.pem privkey.pem

• cert.pem 域名证书
• chain.pem 根证书及中间证书
• fullchain.pem 由 cert.pem 和 chain.pem 合并而成
• privkey.pem 证书私钥

** 创建一个 2048 位的 Diffie-Hellman 文件 **(nginx 默认使用 1024 位的 Diffie–Hellman 进行密钥交换, 安全性太低)

openssl dhparam -out /etc/letsencrypt/live/dhparams.pem 2048

nginx TSL 配置

首先对 http 协议进行 301 重定向到 https 协议

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

https 相关配置

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    
    # 配置站点证书文件地址
    ssl_certificate      /etc/letsencrypt/live/example.com/fullchain.pem;
    # 配置证书私钥
    ssl_certificate_key  /etc/letsencrypt/live/example.com/privkey.pem;
    
    # 配置 Diffie-Hellman 交换算法文件地址
    ssl_dhparam          /etc/letsencrypt/live/dhparams.pem;
    
    # 配置服务器可使用的加密算法
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

    # 指定服务器密码算法在优先于客户端密码算法时，使用 SSLv3 和 TLS 协议
    ssl_prefer_server_ciphers  on;
    
    # ssl 版本 可用 SSLv2,SSLv3,TLSv1,TLSv1.1,TLSv1.2 
    # ie6 只支持 SSLv2,SSLv3 但是存在安全问题, 故不支持
    ssl_protocols        TLSv1 TLSv1.1 TLSv1.2;
    
    # 配置 TLS 握手后生成的 session 缓存空间大小 1m 大约能存储 4000 个 session
    ssl_session_cache          shared:SSL:50m;
    # session 超时时间
    ssl_session_timeout        1d;
    
    # 负载均衡时使用 此处暂时关闭 详情见 https://imququ.com/post/optimize-tls-handshake.html 
    # 1.5.9 及以上支持
    ssl_session_tickets off;
    
    # 浏览器可能会在建立 TLS 连接时在线验证证书有效性，从而阻塞 TLS 握手，拖慢整体速度。OCSP stapling 是一种优化措施，服务端通过它可以在证书链中封装证书颁发机构的 OCSP（Online Certificate Status Protocol）响应，从而让浏览器跳过在线查询。服务端获取 OCSP 一方面更快（因为服务端一般有更好的网络环境），另一方面可以更好地缓存 以上内容来自 https://imququ.com/post/my-nginx-conf-for-wpo.html
    # 1.3.7 及以上支持
    ssl_stapling               on;
    ssl_stapling_verify        on;
    # 根证书 + 中间证书
    ssl_trusted_certificate    /etc/letsencrypt/live/example.com/fullchain.pem;
    
    # HSTS 可以告诉浏览器，在指定的 max-age 内，始终通过 HTTPS 访问该域名。即使用户自己输入 HTTP 的地址，或者点击了 HTTP 链接，浏览器也会在本地替换为 HTTPS 再发送请求 相关配置见 https://imququ.com/post/sth-about-switch-to-https.html
    add_header Strict-Transport-Security max-age=60;
    
    # 在次填写原本 http 协议中的配置
}

以上配置完成后, 重启 nginx 即可完成对 https 的切换

使用以下命令即可进行 ** 续期 **, 续期成功后需要服务器

$ ./certbot-auto renew

该命令只会对快到期的证书才会进行更新, 如果希望强制更新, 可以增加 --force-renewal参数

通过 Qualys SSL labs 提供的 SSL Server Test 服务可以查看网站的当前配置, 以及测试网站安全评分
另外该网站缓存了一些知名网站的测试结果, 点击以下链接可进行查看

• Google
• GitHub
• Stack Overflow
• Twitter
• Facebook

其他说明

如果一个 IP 需要配置多张证书, 请查看 关于启用 HTTPS 的一些经验分享（二） **SNI 扩展 ** 部分
文中 ssl_ciphers 配置参考 Mozilla SSL Configuration Generator 中的常规配置而来
Mozilla 同时也提供 TSL 配置说明文档 Security/Server Side TLS
另外也可参考 cipherli 提供的 TSL 配置模版
除了 ssl_ciphers 配置外, 其他皆是参考 Jerry Qu 的 本博客 Nginx 配置之完整篇 一文而来
另外一些配置的详情, 作用, 原理也可以在他的博客中进行搜索得知
本文同时也参考了以下博客

• HTTPS 升级指南
• 更换 SSL 证书：使用 Let's Encrypt
• Let's Encrypt SSL 证书配置
  另外在配置完成后可以 ** 观看以下博客 **, 以增强对 TSL,nginx 的了解
• 一些安全相关的 HTTP 响应头
• Content Security Policy 介绍
• 关于启用 HTTPS 的一些经验分享（一）
• 关于启用 HTTPS 的一些经验分享（二）
• 关于启用 HTTPS 的一些经验分享（三）
• HTTP Public Key Pinning 介绍
• 本博客 Nginx 配置之安全篇
• 本博客 Nginx 配置之性能篇

Nginx的一些基本功能

2016年10月14日 16:21:29 GE12 阅读数：32198更多

个人分类： nginx

版权声明：转自 http://www.234plus.com/ https://blog.csdn.net/ZhongGuoZhiChuang/article/details/52816887

1、静态HTTP服务器

首先，Nginx是一个HTTP服务器，可以将服务器上的静态文件（如HTML、图片）通过HTTP协议展现给客户端。

配置：

server {
    listen80; # 端口号
    location / {
        root /usr/share/nginx/html; # 静态文件路径
    }
}

2、反向代理服务器

什么是反向代理？

客户端本来可以直接通过HTTP协议访问某网站应用服务器，网站管理员可以在中间加上一个Nginx，客户端请求Nginx，Nginx请求应用服务器，然后将结果返回给客户端，此时Nginx就是反向代理服务器。

配置：

server {








    listen80;








    location / {








        proxy_pass http://192.168.20.1:8080; # 应用服务器HTTP地址








    }








}

既然服务器可以直接HTTP访问，为什么要在中间加上一个反向代理，不是多此一举吗？反向代理有什么作用？继续往下看，下面的负载均衡、虚拟主机等，都基于反向代理实现，当然反向代理的功能也不仅仅是这些。

3、负载均衡

当网站访问量非常大，网站站长开心赚钱的同时，也摊上事儿了。因为网站越来越慢，一台服务器已经不够用了。于是将同一个应用部署在多台服务器上，将大量用户的请求分配给多台机器处理。同时带来的好处是，其中一台服务器万一挂了，只要还有其他服务器正常运行，就不会影响用户使用。

Nginx可以通过反向代理来实现负载均衡。

配置 

upstream myapp {








    server192.168.20.1:8080; # 应用服务器1








    server192.168.20.2:8080; # 应用服务器2








}








server {








    listen80;








    location / {








        proxy_pass http://myapp;








    }








}

以上配置会将请求轮询分配到应用服务器，也就是一个客户端的多次请求，有可能会由多台不同的服务器处理。可以通过ip-hash的方式，根据客户端ip地址的hash值将请求分配给固定的某一个服务器处理。

配置：

upstream myapp {








    ip_hash; # 根据客户端IP地址Hash值将请求分配给固定的一个服务器处理








    server192.168.20.1:8080;








    server192.168.20.2:8080;








}








server {








    listen80;








    location / {








        proxy_pass http://myapp;








    }








}

另外，服务器的硬件配置可能有好有差，想把大部分请求分配给好的服务器，把少量请求分配给差的服务器，可以通过weight来控制。 

配置：

upstream myapp {








    server192.168.20.1:8080weight=3; # 该服务器处理3/4请求








    server192.168.20.2:8080; # weight默认为1，该服务器处理1/4请求








}








server {








    listen80;








    location / {








        proxy_pass http://myapp;








    }








}

4、虚拟主机

有的网站访问量大，需要负载均衡。然而并不是所有网站都如此出色，有的网站，由于访问量太小，需要节省成本，将多个网站部署在同一台服务器上。

例如将www.aaa.com和www.bbb.com两个网站部署在同一台服务器上，两个域名解析到同一个IP地址，但是用户通过两个域名却可以打开两个完全不同的网站，互相不影响，就像访问两个服务器一样，所以叫两个虚拟主机。

配置：

server {








    listen80default_server;








    server_name _;








    return444; # 过滤其他域名的请求，返回444状态码








}








server {








    listen80;








    server_name www.aaa.com; # www.aaa.com域名








    location / {








        proxy_pass http://localhost:8080; # 对应端口号8080








    }








}








server {








    listen80;








    server_name www.bbb.com; # www.bbb.com域名








    location / {








        proxy_pass http://localhost:8081; # 对应端口号8081








    }








}

在服务器8080和8081分别开了一个应用，客户端通过不同的域名访问，根据server_name可以反向代理到对应的应用服务器。

虚拟主机的原理是通过HTTP请求头中的Host是否匹配server_name来实现的，有兴趣的同学可以研究一下HTTP协议。

另外，server_name配置还可以过滤有人恶意将某些域名指向你的主机服务器。

5、FastCGI

Nginx本身不支持PHP等语言，但是它可以通过FastCGI来将请求扔给某些语言或框架处理（例如PHP、Python、Perl）。

server {








    listen80;








    location ~ \.php$ {








        include fastcgi_params;








        fastcgi_param SCRIPT_FILENAME /PHP文件路径$fastcgi_script_name; # PHP文件路径








        fastcgi_pass127.0.0.1:9000; # PHP-FPM地址和端口号








        # 另一种方式：fastcgi_pass unix:/var/run/php5-fpm.sock;








    }








}

配置中将.php结尾的请求通过FashCGI交给PHP-FPM处理，PHP-FPM是PHP的一个FastCGI管理器。有