Nginx konfiguriert den HTTPS-Server

http://nginx.org/cn/docs/http/configuring_https_servers.html

HTTPS-Server konfigurieren

Übersetzte Inhalte sind möglicherweise nicht verfügbar Datum . Die neuesten Updates können Sie über die englische Version einsehen.

HTTPS-Serveroptimierung

HTTPS服务器优化
SSL证书链
合并HTTP/HTTPS主机
基于名字的HTTPS主机
带有多个主机名的SSL证书
主机名指示
兼容性

SSL-ZertifikatsketteHTTP/HTTPS-Hosts zusammenführenNamensbasiertes HTTPS HostSSL-Zertifikat mit mehreren HostnamenHostnamenanzeigeKompatibilität

Um den HTTPS-Host zu konfigurieren, müssen Sie das SSL-Protokoll im Serverkonfigurationsblock öffnen und den Speicherort des serverseitigen Zertifikats und der Schlüsseldateien angeben:

server {
    listen              443;
    server_name         www.example.com;
    ssl                 on;
    ssl_certificate     www.example.com.crt;
    ssl_certificate_key www.example.com.key;
    ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...
}

The Das Serverzertifikat ist öffentlich und wird an jeden Client gesendet, der mit dem Server verbunden ist. Der private Schlüssel ist nicht öffentlich und muss in einer Datei mit eingeschränktem Zugriff gespeichert werden. Natürlich muss der Nginx-Hauptprozess die Berechtigung haben, den Schlüssel zu lesen. Der private Schlüssel und das Zertifikat können in derselben Datei gespeichert werden:

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

In diesem Fall müssen auch Zugriffsbeschränkungen auf die Zertifikatsdatei gesetzt werden. Obwohl das Zertifikat und der Schlüssel in derselben Datei gespeichert sind, wird natürlich nur das Zertifikat an den Client gesendet, nicht der Schlüssel.

Die Anweisungen ssl_protocols und ssl_ciphers können verwendet werden, um Benutzerverbindungen zu zwingen, nur starke Protokollversionen und leistungsstarke Verschlüsselungsalgorithmen von SSL/TLS einzuführen. Ab Version 1.0.5 verwendet Nginx standardmäßig „ssl_protocols SSLv3 TLSv1“ und „ssl_ciphers HIGH:!aNULL:!MD5“, sodass es in früheren Versionen nur sinnvoll war, diese explizit zu konfigurieren. Ab den Versionen 1.1.13 und 1.0.12 verwendet Nginx standardmäßig „ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2“.

Der Verschlüsselungsalgorithmus im CBC-Modus ist anfällig für einige Angriffe, insbesondere den BEAST-Angriff (siehe CVE-2011-3389). Sie können es anpassen, um dem RC4-SHA-Verschlüsselungsalgorithmus durch die folgende Konfiguration Priorität einzuräumen:

    ssl_ciphers RC4:HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

HTTPS-Serveroptimierung

SSL Vorgänge erfordern CPU-Ressourcen, daher müssen in einem Multiprozessorsystem mehrere Arbeitsprozesse gestartet werden, und die Anzahl darf nicht geringer sein als die Anzahl der verfügbaren CPUs. Der SSL-Vorgang, der die meisten CPU-Ressourcen verbraucht, ist der SSL-Handshake. Es gibt zwei Möglichkeiten, die Anzahl der Handshake-Vorgänge für jeden Client zu minimieren: Die erste besteht darin, den Client lange verbunden zu halten und mehrere Anforderungen in einer SSL-Verbindung zu senden Ziel ist es, SSL-Sitzungsparameter in gleichzeitigen oder nachfolgenden Verbindungen wiederzuverwenden und so den SSL-Handshake-Vorgang zu vermeiden. Sitzungscaches werden zum Speichern von SSL-Sitzungen verwendet. Diese Caches werden von Arbeitsprozessen gemeinsam genutzt und können mithilfe der ssl_session_cache-Direktive konfiguriert werden. Ein 1-MB-Cache kann etwa 4.000 Sitzungen speichern. Das Standard-Cache-Timeout beträgt 5 Minuten. Sie können es mit ssl_session_timeout erhöhen. Hier ist ein Beispiel für eine Konfigurationsoptimierung für ein 4-Kern-System unter Verwendung eines 10 MB gemeinsamen Sitzungscache:

worker_processes  4;

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

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

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

SSL-Zertifikatskette

Einige Browser akzeptieren keine von bekannten Zertifizierungsstellen signierten Zertifikate, während andere Browser dies tun. Dies liegt daran, dass bei der Zertifikatsausstellung einige Zwischenzertifizierungsstellen zum Einsatz kommen. Diese Zwischenstellen sind von bekannten Zertifikatszertifizierungsstellen autorisiert, in ihrem Namen Zertifikate auszustellen, sie selbst sind jedoch nicht allgemein anerkannt, sodass sie von einigen Kunden nicht anerkannt werden. Als Reaktion auf diese Situation stellt die Zertifizierungsstelle ein Zertifikatskettenpaket bereit, um die Beziehung zwischen der bekannten Zertifizierungsstelle und sich selbst zu deklarieren. Dieses Zertifikatskettenpaket muss mit dem Serverzertifikat in einer Datei zusammengeführt werden. In dieser Datei muss das Serverzertifikat am Anfang der Authentifizierungszertifikatkette stehen:

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

Auf diese Datei muss mit der ssl_certificate-Direktive verwiesen werden:

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

Wenn das Serverzertifikat und die Authentifizierungszertifikatkette in der falschen Reihenfolge zusammengeführt werden, startet Nginx nicht normal und die folgende Fehlermeldung wird angezeigt:

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

Weil Nginx zuerst den privaten Schlüssel zum Entschlüsseln des Serverzertifikats verwenden muss, aber auf das Zertifikat des Authentifikators stößt.

Browser speichern normalerweise Zwischenzertifizierungsstellen, die von vertrauenswürdigen Zertifizierungsstellen zertifiziert sind. Wenn diese Browser dann auf Situationen stoßen, in denen diese Zwischenzertifizierungsstellen verwendet werden, die Zertifikatskette jedoch in Zukunft nicht mehr einbezogen wird, weil sie gespeichert wurden Informationen dieser Zwischenzertifizierungsstellen sind enthalten, sodass keine Fehler gemeldet werden. Sie können das Befehlszeilentool openssl verwenden, um zu bestätigen, dass der Server die vollständige Zertifikatskette gesendet hat:

$ 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
...

In diesem Beispiel das Serverzertifikat für www.GoDaddy.com ( #0) Der Unterzeichner („s“) wird von der ausstellenden Behörde („i“) signiert, und diese ausstellende Behörde ist der Unterzeichner des Zertifikats (#1), und dann ist es die ausstellende Behörde des Zertifikats (#1). Das Zertifikat (der Empfänger von Nr. 2), das endgültige Zertifikat (Nr. 2) wurde von ValiCert, Inc, einer bekannten ausstellenden Behörde, ausgestellt. Das Zertifikat von ValiCert, Inc. ist im Browser eingebettet und wird vom Browser automatisch erkannt (diese Passage ähnelt dem Inhalt im britischen Gedicht „In the House That Jack Built“).

Wenn die Authentifizierungszertifikatkette nicht hinzugefügt wird, wird nur das Serverzertifikat (#0) angezeigt.

Kombinierter HTTP/HTTPS-Host

Wenn die Funktionen der virtuellen HTTP- und HTTPS-Hosts konsistent sind, können Sie einen virtuellen Host so konfigurieren, dass er sowohl HTTP-Anfragen als auch HTTPS-Anfragen verarbeitet. Die Konfigurationsmethode besteht darin, den Befehl ssl on zu löschen und den Parameter ssl im *:443-Port hinzuzufügen:

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

Vor Version 0.8.21 nur der default wurde hinzugefügt >Der Überwachungsport des Parameters kann den Parameter ssl hinzufügen:

listen  443  default ssl;

Namensbasierter HTTPS-Host

Wenn mehrere HTTPS-Hosts auf derselben IP konfiguriert sind, tritt ein sehr häufiges Problem auf :

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

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

使用上面的配置，不论浏览器请求哪个主机，都只会收到默认主机www.example.com的证书。这是由SSL协议本身的行为引起的——先建立SSL连接，再发送HTTP请求，所以nginx建立SSL连接时不知道所请求主机的名字，因此，它只会返回默认主机的证书。

最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址：

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

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

带有多个主机名的SSL证书

也有其他一些方法可以实现多个HTTPS主机共享一个IP地址，但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书，比如www.example.com和www.example.org。但是，“SubjectAltName”字段的长度有限制。

另一种方式是使用主机名中含有通配符的证书，比如*.example.org。这个证书匹配www.example.org，但是不匹配example.org和www.sub.example.org。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书，这些名字既可以是确切的名字，也可以是通配符，比如example.org和*.example.org。

最好将带有多个名字的证书和它的密钥文件配置在http配置块中，这样可以只保存一份内容拷贝，所有主机的配置都从中继承：

ssl_certificate      common.crt;
ssl_certificate_key  common.key;

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

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

主机名指示

在一个IP上运行多个HTTPS主机的更通用的方案是TLS主机名指示扩展（SNI，RFC6066），它允许浏览器和服务器进行SSL握手时，将请求的主机名传递给服务器，因此服务器可以知道使用哪一个证书来服务这个连接。但SNI只得到有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息：

• Opera 8.0；
• MSIE 7.0（仅在Windows Vista操作系统及后续操作系统）；
• Firefox 2.0和使用Mozilla平台1.8.1版本的其他浏览器；
• Safari 3.2.1（Windows版需要最低Vista操作系统）；
• Chrome（Windows版需要最低Vista操作系统）。

通过SNI只能传递域名，但是，当请求中包含可读的IP地址时，某些浏览器将服务器的IP地址作为服务器的名字进行了传送。这是一个错误，大家不应该依赖于这个。

为了在nginx中使用SNI，那么无论是在编译nginx时使用的OpenSSL类库，还是在运行nginx时使用的OpenSSL运行库，都必须支持SNI。从0.9.8f版本开始，OpenSSL通过“--enable-tlsext”配置选项加入SNI支持，从0.9.8j版本开始，此选项成为默认选项。当nginx被编译成支持SNI时，在使用“-V”选项运行时会显示如下信息：

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

但是，当开启SNI支持的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

兼容性

• 从0.8.21和0.7.62版本开始，使用“-V”选项运行nginx时，将显示SNI支持状态信息。
• 从0.7.14版本开始，listen指令支持ssl参数。
• 从0.5.32版本开始，支持SNI。
• 从0.5.6版本开始，支持SSL会话缓存，并可在工作进程间共享。

• 0.7.65、0.8.19及以后版本，默认SSL协议是SSLv3、TLSv1、TLSc1.1和TLSv1.2（如果OpenSSL库支持）。
• 0.7.64、0.8.18及以前版本，默认SSL协议是SSLv2、SSLv3和TLSv1。

• 1.0.5及以后版本，默认SSL密码算法是HIGH:!aNULL:!MD5。
• 0.7.65、0.8.20及以后版本，默认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。

作者: Igor Sysoev
编辑: Brian Mercer
翻译: cfsego

以上就介绍了nginx 配置HTTPS服务器，包括了方面的内容，希望对PHP教程有兴趣的朋友有所帮助。