澳门新萄京官方网站-www.8455.com-澳门新萄京赌场网址

PHP技师玩转Linux体系

2019-11-04 作者:www.8455.com   |   浏览(99)

1.PHP程序员玩转Linux系列-怎么安装使用CentOS

编译自:
[configuring_https_servers][1]
[1]: http://nginx.org/en/docs/http/configuring_https_servers.html

1  概述

  Nginx上部署HTTPS依赖OpenSSL库和包含文件,即须先安装好libssl-dev(或者OpenSSL),且ln -s /usr/lib/x86_64-linux-gnu/libssl.so  /usr/lib/,然后在编译配置Nginx时要指定--with-http_ssl_module和--with-http_v2_module。另外,若要在本地运行openssl命令,要安装OpenSSL包,本人用的OpenSSL-1.0.2g。注:本文采用Ubuntu 16.04上的操作实例

2.PHP程序员玩转Linux系列-lnmp环境的搭建

目录PHP技师玩转Linux体系。:

要利用nginx软件实现https的页面,要用到ngx_http_ssl_module模块,本文将介绍该模块的几个常见用法,实现一台物理机上创建多个https站点。注意通过nginx -V查看,如果有TLS SNI support enabled,表示支持在一台主机上支持多个https主机

  下图展示了数字证书(HTTPS中使用的由CA签名的公钥证书)的签名和验证原理:图片 1

3.PHP程序员玩转Linux系列-搭建FTP代码开发环境

  • 简介
  • HTTPS 服务器优化
  • SSL 证书链
  • 一个 HTTP/HTTPS 服务器
  • Name-based HTTPS 服务器
    • 多个 server 共享一个 SSL 证书
    • Server Name Indication
  • 兼容性

2  模块配置

 

4.PHP程序员玩转Linux系列-备份还原MySQL

简介


配置 HTTPS 服务,必须为 listen 指令加上 ssl 参数,并指定服务器的证书和私钥:

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 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...
}

服务器证书将被发送给每个连接服务器的客户端。私钥必须在服务器端保存,应该为私钥添加严格的访问限制,nginx 主进程必须对其有读权限。私钥可以和证书存放在同一个文件中:

ssl_certificate     www.example.com.cert;
ssl_certificate_key www.example.com.cert;

这个文件当然也应该加上严格的权限设置。虽然证书和私钥被存放在同一个文件中,但只有证书会被发送给客户端。

使用 ssl_protocols 指令 和 ss_chiphers 指令,可设置加密连接使用高安全性的协议版本以及加密性强的算法(SSL/TLS协议)。nginx 默认使用 “ssl_protocols TLSv1 TLSv1.1 TLSv1.2” 以及 “ssl_ciphers HIGH:!aNULL:!MD5”,它们分别指定了默认的协议版本和加密算法,所以这些算法不需要显式地指定。要注意的是,这两个指令的默认值已经多次发生改变(详见 “兼容性” 小节)。

[listen][2] 指令
[2]: http://nginx.org/en/docs/http/ngx_http_core_module.html#listen

[server][3] 指令
[3]: http://nginx.org/en/docs/http/ngx_http_core_module.html#server

[server certificate][4] 指令
[4]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate

[private key][5] 指令
[5]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate_key

[ssl_protocols][6] 指令
[6]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols

[ss_chiphers][7] 指令
[7]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers

.1、ssl

 

5.PHP程序员玩转Linux系列-自动备份与SVN

HTTPS 服务器优化


处理 SSL 连接会消耗额外的 CPU 资源。在多处理器系统上,应设置对应CPU核心个数的 worker 进程。(参考:worker_processes)

建立 SSL 连接的握手阶段是最消耗 CPU 的,有两种方法可最小化建立每个 SSL 连接所需要的握手操作次数:

  • 第一是启用 keepalive 连接保持。启动连接保持,可以在一个已建立的 SSL 连接上处理多个请求
  • 第二是重用 SSL 会话参数,使并行的或者后续的连接不再需要进行 SSL 握手。

SSL 连接的会话参数被保存在 SSL 会话缓存中,该缓存被所有的 worker 进程共享,可使用 ssl_session_cache 指令对其进行配置。1MB SSL 会话可容纳约 4000 个会话。

默认的缓存超时为 5 分钟,可使用 ssl_session_timeout 指令进行调整。

下面是一个 SSL 优化配置样例,假设系统拥有的 CPU 核心总数为 10个,为其配置 10 MB 的共享会话缓存:

worker_processes auto;

http {
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;

    server {
        listen              443 ssl;
        server_name         www.example.com;
        keepalive_timeout   70;

        ssl_certificate     www.example.com.crt;
        ssl_certificate_key www.example.com.key;
        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers         HIGH:!aNULL:!MD5;
        ...

[ssl_session_cache][9]
[9]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache

[ssl_session_timeout][10]
[10]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_timeout

ssl  on | off;

 

6.PHP程序员玩转Linux系列-Linux和Windows安装nginx

SSL 证书链


有时会出现这样的情况,对一个由知名 CA 签发的证书,一些浏览器发出警告,而另一些浏览器会接受。这是因为签发该证书的 CA 使用了一个 intermediate certificate 签发证书,这个 intermediate certificate 没有包含在跟随浏览器一起分发的证书库中。为应对这个问题,CA 提供了 a bundle of chained certificate ,可将该证书与你的服务器证书合并成一个文件。在这个文件中,服务器的证书必须位于 chained certificate 的前面:

$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt

使用它作为 ssl_certificate 指令的参数:

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     www.example.com.chained.crt;
    ssl_certificate_key www.example.com.key;
    ...
}

如果顺序颠倒了,把服务器证书放在了 chained certificate 的后面,nginx 不能成功启动,并且显示如下错误消息:

SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
   (SSL: error:0B080074:x509 certificate routines:
    X509_check_private_key:key values mismatch)

这是因为 nginx 发现服务器的私钥和 chained certificate 的第一个证书不匹配造成的。

当浏览器收到 intermediate certificates 时,一般都会将它存储下来。所以浏览器可能在第一次收到 intermediate certificates 时发出警告,但存储下来之后再次收到时就不会发出警告了。

要确定一个 web 服务器是否发送了完整的 certificate chain,可使用 openssl 命令:

$ openssl s_client -connect www.godaddy.com:443
...
Certificate chain
 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
     /OU=MIS Department/CN=www.GoDaddy.com
     /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc.
     /OU=ValiCert Class 2 Policy Validation Authority
     /CN=http://www.valicert.com//emailAddress=info@valicert.com
...
Server certificate
-----BEGIN CERTIFICATE----- 
...

在此例中的 Certificate chain 中,#0号证书的对象 (“s”) 的证书颁发者是 (“i”),#0证书的 (“i”) 同时又是 #1 号证书的对象 (“s”);#1号证书颁发者 (“i”) 是 #2号证书的对象 (“s”),#2号证书的颁发者 (“i”) 是知名 CA “ValiCert, Inc”,这个 CA 的证书是存储在随浏览器分发的内建证书库中的。

如果服务器发送给客户端的证书没有包含 certificate chain,上面的信息只会显示 #0 号服务器证书。

为指定虚拟机启用HTTPS  protocol,建议用listen指令代替

  • TLS保障信息传输安全:对于每一次新的对话(连接握手阶段。这里讲的对话不是HTTP中涉及的应用层对话,而是TLS对话),客户端和服务端都会协商一个对话密钥和对称加密算法(了解更多可参考“加密套件”“四次握手”相关内容)用来加解密信息,这样就避免非对称加解密耗时过长,运算速度更快;而Public/Private密钥对只用于"pre-master key"的加解密。特别地,在连接断开后,旧对话的恢复(两种实现方法:session ID和session ticket)不属于建立新的对话,无需协商一个新的对话密钥和对称加密算法。

7.PHP程序员玩转Linux系列-nginx初学者引导

一个 HTTP/HTTPS 服务器


建立一个可同时处理 HTTP 和 HTTPS 请求的 web 服务器:

server {
    listen              80;
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     www.example.com.crt;
    ssl_certificate_key www.example.com.key;
    ...
}

Note:
nginx 0.7.14 版之前,不支持像上面这样单独将某个监听套接字设置为 SSL 连接。
只能在 server 区块中使用 ssl {on|off} 指令,定义整个 server 提供 HTTPS 服务,
因此不能设置可同时处理 HTTP/HTTPS 请求的 server 区块。现在不建议在新版本的 nginx 
中使用 ssl 指令,建议使用 ssl 参数。

.2、ssl_certificate

 

 

Name-based HTTPS 服务器


基于名称的 HTTPS 服务器。

子目录

  • 概念讲解
  • 多个 server 共享一个 SSL 证书
  • Server Name Indication

ssl_certificate  file;

  • HTTP2:HTTP2 基于SPDY设计,支持HTTPS。但HTTP2与SPDY不同的是,不强制使用 HTTPS,但目前还没有浏览器支持;HTTP2 消息头的压缩算法采用 HPACK ,而非 SPDY 采用的 DELEFT。HTTP2基本兼容HTTP1.x的语义,只是改变了HTTP1.x的传输方式,在连接中是否使用HTTP2是通过协议协商(NPN、ALPN或Upgrade头)来决定的。HTTP2拥有许多新特性:

创建一个HTTPS服务器

概念讲解


如何设置监听于一个 IP 地址的多个 HTTPS 服务器?

server {
    listen          443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}

虽然在这样的配置中为两个 server 设置了不同的证书,但是当使用浏览器访问该 web 站点时,无论访问的主机名是 www.example.com 还是 www.example.org,浏览器都将收到同一个服务器证书:服务器的默认证书。在这里的默认证书是 www.example.com.crt。

这是由 SSL 协议的行为所决定的。SSL 连接建立于 TCP/IP 连接之上,SSL 连接在握手的阶段,会收到由 nginx 服务器发送的服务器证书,SSL 连接建完成之时,浏览器还没有发送 HTTP 请求给 nginx,因此 nginx 无法在建立 SSL 连接时得知浏览器所请求的是哪一个虚拟主机,因此,nginx 只能发送默认的服务器证书给浏览器。

对于这个问题,最老的方法,也是最 robust 的方法,是为每个 HTTPS 服务设置独立的 IP 地址:

server {
    listen          192.168.1.1:443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          192.168.1.2:443 ssl;
    server_name     www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}

当前虚拟主机使用PEM格式的证书文件

  1. 二进制协议:HTTP2.0协议采用二进制格式,实现方便且健壮;HTTP1.x采用的是文本格式
  2. 头部压缩:HTTP/1.x 每次请求,都会携带大量冗余头信息,浪费了很多带宽资源,头压缩能够很好的解决该问题
  3. 多路复用:多个请求和响应通过一个 TCP 连接并发完成,还支持请求优先级划分和流控制
  4. Server Push:服务端可以主动把 JS 和 CSS 文件推送给客户端,而不需要客户端先解析 HTML 再发送这些请求。当客户端需要的时候,它们已经在客户端了

 

多个 server 共享一个 SSL 证书


有多种方式可实现在多个 HTTPS servers 之间共享一个 IP 地址,但这些方法都有各自的缺点。

一种方法是在证书的 SubjectAltName 字段中设置多个主机名,比如设置两个主机名:www.example.com 和 www.example.org。缺点是 SubjectAltName 字段的长度是有限制的。

另一种方法是在证书中设置“通配主机名”,比如 *.example.org,但它只能匹配一个名字区域的主机名,比如,它不能匹配 example.org 和 www.sub.example.org。

以上两种方法可以结合使用,也就是在证书的 SubjectAltName 字段中同时包含多个 “准确主机名” 和 “通配主机名”。比如同时包含:example.org 和 *.example.org。

对于这种在多个 HTTPS servers 之间共享一个 IP 地址的应用场景,最好在配置中,将服务器的证书和私钥放到 http 区块中,使得所有的 server 区块可继承该配置:

ssl_certificate     common.crt;
ssl_certificate_key common.key;

server {
    listen          443 ssl;
    server_name     www.example.com;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ...
}

创建自签名的证书文件

  下图是HTTP2 Frame 格式:RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)

在nginx.conf配置文件中,在server块里面通过listen指令指定ssl的参数,设置好服务器证书和私钥文件的路径

Server Name Indication


对于实现在多个 HTTPS servers 之间共享一个 IP 地址,或者说基于同一个 IP 地址运行多个 HTTPS server,一种更为通用的解决方案是使用 TLS Server Name Indication extension (SNI, RFC 6066)。

通过 SNI 可允许浏览器在与 web 服务器进行 SSL 握手的阶段,将所请求的 server name 传递给服务器,这样服务器就能够为这个 SSL 连接选择对应的证书。

但是 SNI 对浏览器的版本有要求,目前支持 SNI 的浏览器版本如下:

Opera 8.0;
MSIE 7.0 (but only on Windows Vista or higher);
Firefox 2.0 and other browsers using Mozilla Platform rv:1.8.1;
Safari 3.2.1 (Windows version supports SNI on Vista or higher);
and Chrome (Windows version supports SNI on Vista or higher, too).

Note:
在 SNI 中只能传递 domain names(域名)。如果一个访问请求中包含有 IP 地址,
一些浏览器会错误地将服务器的 IP 地址当做所请求的主机名传递给服务器。因此,不能
完全依赖 SNI。

为了在 nginx 中使用 SNI,要求两种函数库支持 SNI:一是 nginx 编译时使用的 OpenSSL 库,二是 nginx 在运行时动态链接的库。OpenSSL 从 0.9.8f 版开始支持 SNI(要求 OpenSSL 在编译时使用了 “--enable-tlsext” 选项)。从 0.9.8j 版开始,该选择是默认的选项。如果 nginx 编译进了对 SNI 的支持,那么使用 nginx -V 命令查看时,可看到:

$ nginx -V
...
TLS SNI support enabled
...

附上译者的测试:

[root@lamp1 ~]# nginx -V
nginx version: nginx/1.10.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
...

如果 SNI-enabled nginx 动态链接不支持 SNI 的 OpenSSL 库,nginx 将显示如下警告:

nginx was built with SNI support, however, now it is linked
dynamically to an OpenSSL library which has no tlsext support,
therefore SNI is not available

cd /etc/pki/tls/certs/

  图片 2

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 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...
}

兼容性


从 0.8.21 和 0.7.62 开始,可使用 nginx -V 显示 SNI 支持状态信息。

从 0.7.14 开始,nginx 支持在 listen 指令中使用 ssl 参数,而且在 0.8.21 之前,ssl 参数只能和 default 参数一起使用。

从 0.5.32 开始支持 SNI。
从 0.5.6 开始支持 SSL 会话缓存。

从 1.9.1 开始,默认的 SSL 协议为 TLSv1, TLSv1.1, and TLSv1.2 (if supported by the OpenSSL library)
从 0.7.65, 0.8.19 开始,到 1.9.1 之前,默认的 SSL 协议为 SSLv3, TLSv1, TLSv1.1, and TLSv1.2 (if supported by the OpenSSL library)。
0.7.64, 0.8.18 及之前,默认的 SSL 协议为 SSLv2, SSLv3, and TLSv1。

从 1.0.5 开始,默认的 SSL 加密算法为 “HIGH:!aNULL:!MD5”。
0.7.65, 0.8.20 之后,1.0.5 之前,默认的 SSL 加密算法为 “HIGH:!ADH:!MD5”。
0.8.19: 默认的 SSL 加密算法为 “ALL:!ADH:RC4 RSA: HIGH: MEDIUM”。
0.7.64, 0.8.18 及之前,默认的 SSL 加密算法为 “ALL:!ADH:RC4 RSA: HIGH: MEDIUM: LOW: SSLv2: EXP”。

written by Igor Sysoev
edited by Brian Mercer


版权信息
本文编译自 nginx.org 的部分,遵循其原来的 licence 声明: 2-clause BSD-like license

make nginx6.crt

  图片 3

服务器证书是一个公开实体,它会被发送给每一个连接过来的客户端.私钥是一个安全实体,它应该被存储在一个限制权限的文件中.但是nginx的master进程必须能够读到该私钥文件. 私钥也可以和证书放在一个文件里面.

将生成的私钥文件解密

 

ssl_certificate www.example.com.cert;
ssl_certificate_key www.example.com.cert;

openssl rsa -in nginx6.key-out nginx66.key

  • Nginx上部署HTTPS HTTP2

在这个例子里面,文件的访问权限应该被限制.尽管证书和私钥在一个文件里面,只有证书会被发送给客户端.

将这两个文件复制到配置文件里指定的路径即可

  1. 自签发证书:开发测试环境下可以在其他机器上去生成证书,然后再将所生成server.crt和server.key复制一份至Nginx的/usr/local/nginx/conf下即可

    $ cd /usr/local/nginx/conf
    $ openssl genrsa -des3 -out server.key 1024 #建议:2048
    $ openssl req -new -key server.key -out server.csr #证书签名请求(CSR)
    $ cp server.key server.key.org
    $ openssl rsa -in server.key.org -out server.key
    $ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt #证书签名
    
  2. 修改配置文件nginx.conf:为减少CPU负载,建议只运行一个工作进程,并且开启keep-alive。另外,version 0.6.7以上的Nginx ssl_certificate和ssl_certificate_key的默认关联目录为nginx.conf所在的目录,默认文件名都为cert.pem

    worker_processes 1;
    server {
    
        server_name YOUR_DOMAINNAME_HERE;
        listen 443 ssl http2;# http2 is available only since OpenSSL version 1.0.2
        listen 80;
        if ($scheme = http) {
                rewrite ^(.*)$ https://$server_name$1 permanent;
        }
        ssl_certificate server.crt;
        ssl_certificate_key server.key;
        keepalive_timeout    70;
    }
    

     

  3. 重启Nginx:HTTPS在Nginx上的部署至此已近完毕,然后就可以通过

ssl_protocols 和ssl_ciphers 指令可以被用来限制连接,只包含高版本的TLS和SSL/TLS的密码

在客户的上查看生成的证书信息,命令如下

    图片 4 

从nginx 1.0.5版本开始,nginx默认使用ssl_protocols SSLv3 TLSv1和ssl_ciphers HIGH:!aNULL:!MD5.从nginx 1.1.13 和 1.0.12 版本开始,默认更新成了 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 

openssl s_client -connect  www.e.com:443

  另外,本人在Chromium 58.0.3029.110 和 Firefox 53.0.3 下均证实了HTTP2被成功启用:

 

.3、ssl_certificate_key

  图片 5

一个单一的HTTP和HTTPS服务

ssl_certificate_key  file;

 

可以配置一个服务同时支持HTTP和HTTPS请求, 在虚拟主机中使用listen指令,一个带着ssl参数,一个不带参数.

当前虚拟主机上与其证书匹配的私钥文件

  • 私钥保护:私钥是重要的财产,尽可能限制能接触到私钥的人
server {
    listen              80;
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     www.example.com.crt;
    ssl_certificate_key www.example.com.key;
    ...
}

.4、ssl_protocols

  1. 在一台可信的计算机上生成私钥和CSR(Certificate Signing Requests)。有一些CA会为你生成密钥和CSR,但这样做明显不妥
  2. 受密码保护的密钥可以阻止在备份系统中被截获
  3. 在发现被截获后,撤回老的证书,生成新的密钥和证书
  4. 每年更新证书,总是使用最新的私钥

在nginx 0.7.13和更早的版本中,SSL不能被单独设置监听socket.只能通过ssl指令为全部server开启SSL,才能实现HTTP/HTTPS同时支持.为了解决这一问题,为listen指令添加了ssl参数.因此在0.7.14和之后的版本中,ssl指令不能再用了.  

ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];

 

 

支持ssl协议版本,默认为后三个,主流版本是[TLSv1.2]

  • 部署证书链:证书链(Certificate Chain)包括信任锚(CA 证书)和签名证书,是由一系列 CA 证书发出的证书序列,最终以根 CA 证书结束;Web 浏览器已预先配置了一组浏览器自动信任的根 CA 证书,来自其他证书授权机构的所有证书都必须附带证书链,以检验这些证书的有效性。在很多部署场景中,单一的服务器证书显得不足,而多个证书则需要建立一个信任链。一个常见的问题是正确的配置了服务器证书但却搞忘了包含其他所需要的证书。此外,虽然其他证书通常有很长的有效期,但它们也会过期,如果它们过期就会影响整个链条。一个无效证书链会导致服务器证书失效和客户端浏览器报警告,这个问题有时候不是那么容易被检测到,因为有些浏览器可以自己重构一个完整的信任链而有些则不行。关于Nginx上部署证书链:
    if you have a chain certificate file (sometimes called an intermediate certificate)
    you don't specify it separately like you do in Apache. Instead you need to add the 
    information from the chain cert to the end of your main certificate file. This can be done 
    by typing "cat chain.crt >> mysite.com.crt" on the command line. Once that is done you
    won't use the chain cert file for anything else, you just point Nginx to the main certificate file
    

基于名称的HTTPS服务

.5、ssl_session_cache

   下图展示了证书链的工作原理:

一个很普遍的问题出现了,那就是解决当在一个ip地址配置监听两个或多个HTTPS服务.

ssl_session_cache off | none | [builtin[:size]] [shared:name:size];

     图片 6 

server {
    listen          443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}

builtin[:size]:使用OpenSSL内建缓存,为每worker进程私有,开启多大的空间来作为缓存空间

 

使用这个配置,浏览器只能接收到默认的证书,在这个例子中就是www.example.com证书.这个是因为SSL协议本身造成的.SSL的连接是在浏览器发送HTTP请求之前建立的,因此nginx不知道请求的名称.所以它只能提供默认服务的证书.

[shared:name:size]:在各worker之间使用一个共享的缓存,这样会提高缓存的命中率,提高性能。

  • Nginx上SSL配置指令说明:下边只列举了部分,更多配置项可参考 。

解决这一问题最好的方式是分配不同的IP地址给每一个HTTPS服务

.6、ssl_session_timeout

  1. ssl:开启HTTPS

    syntax:*ssl [on|off]*

    default:*ssl off*

    context:*main, server*

  2. ssl_certificate:证书文件,默认证书和密钥都位于cert.pem中,该文件还可以包含其他证书。自version 0.6.7起,ssl_certificate的默认关联目录为nginx.conf所在的目录。

    syntax:*ssl_certificate file*

    default:*ssl_certificate cert.pem*

    context:*main, server *

  3. ssl_certificate_key:证书密钥文件,默认密钥位于cert.pem中。自version 0.6.7起,ssl_certificate_key的默认关联目录为nginx.conf所在的目录。

    syntax:*ssl_certificate_key file*

    default:*ssl_certificate_key cert.pem*

    context:*main, server*

  4. ssl_client_certificate:Indicates file with certificates CA in PEM format, utilized for checking the client certificates.

    syntax:*ssl_client_certificate file*

    default:*none*

    context:*main, server*

  5. ssl_dhparam:Indicates file with Diffie-Hellman parameters in PEM format, utilized for negotiating TLS session keys.

    syntax: ssl_dhparam file

    default: none

    context: main, server 

  6. ssl_ciphers:Directive describes the permitted ciphers. Ciphers are assigned in the formats supported by OpenSSL.

    syntax: ssl_ciphers file

    default: ssl_ciphers ALL:!ADH:RC4 RSA: HIGH: MEDIUM: LOW: SSLv2: EXP

    context: main, server

    ssl_ciphers ALL:!ADH:!EXPORT56:RC4 RSA: HIGH: MEDIUM: LOW: SSLv2: EXP;
    

    Complete list can be looked with the following command:

    openssl ciphers
    

     

  7. ssl_prefer_server_ciphers:Requires protocols SSLv3 and TLSv1 server ciphers be preferred over the client's ciphers.

    syntax: ssl_prefer_server_ciphers [on|off]

    default: ssl_prefer_server_ciphers off

    context: main, server

  8. ssl_protocols:Directive enables the protocols indicated. TLS v1.0以上的版本是比较安全的,最好是弃用SSLv3以下的版本,SSLv2以下坚决不用

    syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1]

    default: ssl_protocols SSLv2 SSLv3 TLSv1

    context: main, server

  9. ssl_session_cache:The directive sets the types and sizes of caches to store the SSL sessions.

    syntax:*ssl_session_cache off|none|builtin:size and/or shared:name:size*

    default:*ssl_session_cache off*

    context:*main, server*

    ssl_session_cache builtin:1000 shared:SSL:10m;
    

     

  10. ssl_session_timeout:Assigns the time during which the client can repeatedly use the parameters of the session, which is stored in the cache.

    syntax:*ssl_session_timeout time*

    default:*ssl_session_timeout 5m*

    context:*main, server*

server {
    listen          192.168.1.1:443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          192.168.1.2:443 ssl;
    server_name     www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}

ssl_session_timeout  time;

 

  

客户端连接可以复用sslsession cache中缓存的ssl参数的有效时长,默认5m

  • Nginx上HTTP2配置指令说明:详情可参考 

使用多个名称生成SSL证书

3  配置实例

 

这里有其他的方式解决上面的问题,但是每一种都有各自的缺点.一种方式是生成证书的时候更改SubjectAltName字段,比如: www.example.com 和 www.example.org 两个,但是这个字段有长度限制.

创建两台虚拟https主机

  • 参考

另一种方式是证书名称那里使用通配符,比如: *.example.org,但是 通配符名称只能用在一级子域名上.这个名称可以匹配www.example.org ,但是不能匹配example.org或 www.sub.example.org 

vim  /etc/nginx/conf.d/https.conf

  1. 图解SSL/TLS协议:
  2. SSL/TLS协议运行机制的概述
  3. SSL/TLS部署最佳实践
  4. RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
  5. HTTP/2 的协议协商机制
  6. Nginx HttpSSL

这两种方式可以结合起来,在SubjectAltName字段里填上 example.org 和 *.example.org

server{

最好把多域名证书和私钥放在配置http块中,这样所有的服务都可以继承这个配置

listen 443 ssl;

ssl_certificate     common.crt;
ssl_certificate_key common.key;

server {
    listen          443 ssl;
    server_name     www.example.com;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ...
}

server_name www.e.com;

  

root /app/website5;

 

ssl_certificate /etc/nginx/ssl/nginx5.crt;

ssl_certificate_key/etc/nginx/ssl/nginx5.key;

ssl_session_cache shared:sslcache:20m;

ssl_session_timeout 10m;

}

server{

listen 443 ssl;

server_name www.f.com;

root /app/website6;

ssl_certificate /etc/nginx/ssl/nginx6.crt;

ssl_certificate_key/etc/nginx/ssl/nginx6.key;

ssl_session_cache shared:sslcache:20m;

ssl_session_timeout 10m;

}

本文由澳门新萄京官方网站发布于www.8455.com,转载请注明出处:PHP技师玩转Linux体系

关键词: