Zum Inhalt springen

Nginx/https: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
 
(44 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''{{BASEPAGENAME}}''' - Beschreibung
'''nginx/https''' - Konfigurieren von [[HTTPS]]-Servern


== Beschreibung ==
== Beschreibung ==
; HTTPS-Server konfigurieren
* Parameter <tt>ssl</tt> unter [https://nginx.org/en/docs/http/ngx_http_core_module.html#listen listening sockets]
* Im Block [https://nginx.org/en/docs/http/ngx_http_core_module.html#server server] aktiviert werden
* Die Speicherorte der Dateien angeben
** [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate Serverzertifikat]
** [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate_key privater Schlüssel]


== Installation ==
Beispiel
<syntaxhighlight lang="bash" highlight="1" line copy>
<syntaxhighlight lang="nginx" highlight="" line copy>
< /syntaxhighlight>
 
== Aufruf ==
<syntaxhighlight lang="bash" highlight="1" line copy>
< /syntaxhighlight>
 
=== Optionen ===
{| class="wikitable sortable options gnu big"
|-
! Unix !! GNU !! Parameter !! Beschreibung
|-
| || || ||
|-
|}
 
=== Parameter ===
=== Umgebungsvariablen ===
=== Exit-Status ===
{| class="wikitable options col1center big"
|-
! Wert !! Beschreibung
|-
| 0 || Erfolg
|-
| >0  || Fehler
|}
 
== Anwendung ==
<syntaxhighlight lang="bash" highlight="1" line copy>
< /syntaxhighlight>
 
=== Problembehebung ===
 
== Konfiguration ==
=== Dateien ===
{| class="wikitable options big"
|-
! Datei !! Beschreibung
|-
| ||
|-
| ||
|}
 
<noinclude>
 
== Anhang ==
=== Siehe auch ===
<div style="column-count:2">
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
</div>
----
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
 
=== Dokumentation ===
; Man-Page
# [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)]
 
<!--
; Info-Pages
-->
 
=== Links ===
==== Projekt ====
==== Weblinks ====
 
{{DEFAULTSORT:new}}
{{DISPLAYTITLE:new}}
 
[[Kategorie:new]]
 
</noinclude>
= TMP =
== Configuring HTTPS servers ==
To configure an HTTPS server, the <tt>ssl</tt> parameter must be enabled on [https://nginx.org/en/docs/http/ngx_http_core_module.html#listen listening sockets] in the [https://nginx.org/en/docs/http/ngx_http_core_module.html#server server] block, and the locations of the [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate server certificate] and [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate_key private key] files should be specified:
 
server {
server {
    listen             443 ssl;
listen 443 ssl;
    server_name         www.example.com;
server_name www.example.com;
    ssl_certificate     www.example.com.crt;
ssl_certificate www.example.com.crt;
    ssl_certificate_key www.example.com.key;
ssl_certificate_key www.example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
ssl_ciphers HIGH:!aNULL:!MD5;
    ...
..
}
}
</syntaxhighlight>


The server certificate is a public entity. It is sent to every client that connects to the server. The private key is a secure entity and should be stored in a file with restricted access, however, it must be readable by nginx’s master process. The private key may alternately be stored in the same file as the certificate:
; Das Serverzertifikat ist eine öffentliche Entität
* Es wird an jeden Client gesendet, der sich mit dem Server verbindet
* Der private Schlüssel ist eine sichere Entität und sollte in einer Datei mit eingeschränktem Zugriff gespeichert werden, muss jedoch für den Master-Prozess von nginx lesbar sein


    ssl_certificate     www.example.com.cert;
; Der private Schlüssel kann alternativ in derselben Datei wie das Zertifikat gespeichert werden
    ssl_certificate_key www.example.com.cert;
<syntaxhighlight lang="nginx" highlight="" line copy>
ssl_certificate www.example.com.cert;
ssl_certificate_key www.example.com.cert;
</syntaxhighlight>


in which case the file access rights should also be restricted. Although the certificate and the key are stored in one file, only the certificate is sent to a client.
; Dateizugriffsrechte
In diesem Fall sollten auch die Dateizugriffsrechte eingeschränkt werden
* Obwohl das Zertifikat und der Schlüssel in einer Datei gespeichert sind, wird nur das Zertifikat an einen Client gesendet


The directives [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols ssl_protocols] and [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers ssl_ciphers] can be used to limit connections to include only the strong versions and ciphers of SSL/TLS. By default nginx uses “<tt>ssl_protocols TLSv1.2 TLSv1.3</tt>” and “<tt>ssl_ciphers HIGH:!aNULL:!MD5</tt>”, so configuring them explicitly is generally not needed. Note that default values of these directives were [https://nginx.org/en/docs/http/configuring_https_servers.html#compatibility changed] several times.
; Direktiven
Mit den Direktiven [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols ssl_protocols] und [https://nginx.org/en/docs/http/ngx_http_ssl_module.html# ssl_ciphers ssl_ciphers] können verwendet werden, um Verbindungen so zu beschränken, dass nur die starken Versionen und Verschlüsselungen von SSL/TLS zugelassen werden
* Standardmäßig verwendet nginx „<tt>ssl_protocols TLSv1.2 TLSv1.3</tt>” und „<tt>ssl_ciphers HIGH:!aNULL:! MD5</tt>”, sodass eine explizite Konfiguration in der Regel nicht erforderlich ist
* Beachten Sie, dass die Standardwerte dieser Direktiven mehrmals geändert wurden [https://nginx.org/en/docs/http/configuring_https_servers.html#compatibility]


== HTTPS server optimization ==
== HTTPS-Serveroptimierung ==
; SSL-Operationen verbrauchen zusätzliche CPU-Ressourcen
Auf Multiprozessorsystemen sollten mehrere [https://nginx.org/en/docs/ngx_core_module.html#worker_processes Worker-Prozesse] ausgeführt werden, mindestens jedoch so viele wie die Anzahl der verfügbaren CPU-Kerne
* Der CPU-intensivste Vorgang ist der SSL-Handshake
* Es gibt zwei Möglichkeiten, die Anzahl dieser Vorgänge pro Client zu minimieren: Die erste besteht darin, [https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout Keepalive]-Verbindungen zu aktivieren, um mehrere Anfragen über eine Verbindung zu senden, und die zweite darin, SSL-Sitzungsparameter wiederzuverwenden, um SSL-Handshakes für parallele und nachfolgende Verbindungen zu vermeiden
* Die Sitzungen werden in einem SSL-Sitzungscache gespeichert, der von den Arbeitern gemeinsam genutzt und durch die Direktive [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache ssl_session_cache] konfiguriert wird
* Ein Megabyte des Caches enthält etwa 4000 Sitzungen
* Die Standard-Cache-Zeitüberschreitung beträgt 5 Minuten


SSL operations consume extra CPU resources. On multi-processor systems several [https://nginx.org/en/docs/ngx_core_module.html#worker_processes worker processes] should be run, no less than the number of available CPU cores. The most CPU-intensive operation is the SSL handshake. There are two ways to minimize the number of these operations per client: the first is by enabling [https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout keepalive] connections to send several requests via one connection and the second is to reuse SSL session parameters to avoid SSL handshakes for parallel and subsequent connections. The sessions are stored in an SSL session cache shared between workers and configured by the [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache ssl_session_cache] directive. One megabyte of the cache contains about 4000 sessions. The default cache timeout is 5 minutes. It can be increased by using the [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_timeout ssl_session_timeout] directive. Here is a sample configuration optimized for a multi-core system with 10 megabyte shared session cache:
Sie kann mit der Direktive [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_timeout ssl_session_timeout] erhöht werden


Hier ist eine Beispielkonfiguration, die für ein Multi-Core-System mit einem gemeinsam genutzten 10-Megabyte-Sitzungscache optimiert ist
<syntaxhighlight lang="nginx" highlight="" line copy>
worker_processes auto;
worker_processes auto;
http {
http {
    ssl_session_cache   shared:SSL:10m;
ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
ssl_session_timeout 10m;


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


        ssl_certificate     www.example.com.crt;
ssl_certificate www.example.com.crt;
        ssl_certificate_key www.example.com.key;
ssl_certificate_key www.example.com.key;
        ssl_protocols       TLSv1.2 TLSv1.3;
ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers         HIGH:!aNULL:!MD5;
ssl_ciphers HIGH:!aNULL:!MD5;
        ...
..
</syntaxhighlight>


== SSL certificate chains ==
== Zertifikatsketten ==
Einige Browser melden möglicherweise Fehler bei einem Zertifikat, das von einer bekannten Zertifizierungsstelle signiert wurde, während andere Browser das Zertifikat ohne Probleme akzeptieren
* Dies geschieht, weil die ausstellende Stelle das Serverzertifikat mit einem Zwischenzertifikat signiert hat, das nicht in der Zertifikatsdatenbank der bekannten vertrauenswürdigen Zertifizierungsstellen enthalten ist, die mit einem bestimmten Browser verteilt wird
* In diesem Fall stellt die Stelle ein Bündel verketteter Zertifikate bereit, die an das signierte Serverzertifikat angehängt werden sollten


Some browsers may complain about a certificate signed by a well-known certificate authority, while other browsers may accept the certificate without issues. This occurs because the issuing authority has signed the server certificate using an intermediate certificate that is not present in the certificate base of well-known trusted certificate authorities which is distributed with a particular browser. In this case the authority provides a bundle of chained certificates which should be concatenated to the signed server certificate. The server certificate must appear before the chained certificates in the combined file:
Das Serverzertifikat muss in der kombinierten Datei vor den verketteten Zertifikaten erscheinen
 
<syntaxhighlight lang="bash" highlight="1" line copy>
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
cat www.example.com.crt bundle.crt > www.example.com.chained.crt
 
</syntaxhighlight>
The resulting file should be used in the [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate ssl_certificate] directive:


Die resultierende Datei sollte in der Anweisung [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate ssl_certificate] verwendet werden
<syntaxhighlight lang="nginx" highlight="" line copy>
server {
server {
    listen             443 ssl;
listen 443 ssl;
    server_name         www.example.com;
server_name www.example.com;
    ssl_certificate     www.example.com.chained.crt;
ssl_certificate www.example.com.chained.crt;
    ssl_certificate_key www.example.com.key;
ssl_certificate_key www.example.com.key;
    ...
..
}
}
</syntaxhighlight>


If the server certificate and the bundle have been concatenated in the wrong order, nginx will fail to start and will display the error message:  
; Reihenfolge
Wenn das Serverzertifikat und das Bundle in der falschen Reihenfolge verkettet wurden, kann nginx nicht gestartet werden und zeigt die folgende Fehlermeldung an
<syntaxhighlight lang="nginx" highlight="" line>
SSL_CTX_use_PrivateKey_file(„ ... /www.example.com.key“) fehlgeschlagen
(SSL: Fehler:05800074:x509 Zertifikatsroutinen::Schlüsselwerte stimmen nicht überein)
</syntaxhighlight>
da nginx versucht hat, den privaten Schlüssel mit dem ersten Zertifikat des Bundles anstelle des Serverzertifikats zu verwenden


SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
; Zwischenzertifikate
    (SSL: error:05800074:x509 certificate routines::key values mismatch)
Browser speichern in der Regel Zwischenzertifikate, die sie erhalten und die von vertrauenswürdigen Stellen signiert sind
* Daher verfügen aktiv genutzte Browser möglicherweise bereits über die erforderlichen Zwischenzertifikate und melden keine Fehler, wenn ein Zertifikat ohne verkettetes Bundle gesendet wird
* Um sicherzustellen, dass der Server die vollständige Zertifikatskette sendet, kann das Befehlszeilenprogramm <tt>openssl</tt> verwendet werden


because nginx has tried to use the private key with the bundle’s first certificate instead of the server certificate.  
; Beispiel
<syntaxhighlight lang="bash" highlight="1" line copy>
openssl s_client -connect www.godaddy.com:443
</syntaxhighlight>


Browsers usually store intermediate certificates which they receive and which are signed by trusted authorities, so actively used browsers may already have the required intermediate certificates and may not complain about a certificate sent without a chained bundle. To ensure the server sends the complete certificate chain, the <tt>openssl</tt> command-line utility may be used, for example:
<syntaxhighlight lang="bash" highlight="" line>
..
Zertifikatskette
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, Klausel 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
..
</syntaxhighlight>


$ openssl s_client -connect www.godaddy.com:443
In diesem Beispiel wird
...
* das Subjekt („s“) des <tt>www. GoDaddy.com</tt>-Serverzertifikats Nr. 0 von einem Aussteller („i“) signiert, der selbst das Subjekt des Zertifikats Nr. 1 ist, das von einem Aussteller signiert wurde, der selbst das Subjekt des Zertifikats Nr. 2 ist, das von dem bekannten Aussteller ValiCert, Inc. signiert wurde, dessen Zertifikat in der integrierten Zertifikatsdatenbank des Browsers gespeichert ist (die in dem Haus lag, das Jack gebaut hatte)
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 this example the subject (“s”) of the <tt>www.GoDaddy.com</tt> server certificate #0 is signed by an issuer (“i”) which itself is the subject of the certificate #1, which is signed by an issuer which itself is the subject of the certificate #2, which signed by the well-known issuer ValiCert, Inc. whose certificate is stored in the browsers’ built-in certificate base (that lay in the house that Jack built).
Wenn kein Zertifikatspaket hinzugefügt wurde, wird nur das Serverzertifikat Nr. 0 angezeigt


If a certificate bundle has not been added, only the server certificate #0 will be shown.  
== Einzelner Server ==
; Ein einzelner HTTP/HTTPS-Server
Es ist möglich, einen einzelnen Server zu konfigurieren, der sowohl HTTP- als auch HTTPS-Anfragen verarbeitet
<syntaxhighlight lang="nginx" highlight="" line copy>
server {
listen 80;
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
..
}
</syntaxhighlight>


== A single HTTP/HTTPS server ==
Vor 0.7.14 konnte SSL nicht selektiv für einzelne Listening-Sockets aktiviert werden, wie oben gezeigt
 
* SSL konnte nur für den gesamten Server mit der Anweisung [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl ssl] aktiviert werden, wodurch es unmöglich war, einen einzelnen HTTP/HTTPS-Server einzurichten
It is possible to configure a single server that handles both HTTP and HTTPS requests:
* Der Parameter <tt>ssl</tt> der Anweisung [https://nginx.org/en/docs/http/ngx_http_core_module.html#listen listen] wurde hinzugefügt, um dieses Problem zu beheben
 
* Die Verwendung der Direktive [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl ssl] in modernen Versionen wird daher nicht empfohlen; sie wurde in 1.25.1 entfernt
server {
    listen              80;
    listen              443 ssl;
    server_name        www.example.com;
    ssl_certificate    www.example.com.crt;
    ssl_certificate_key www.example.com.key;
    ...
}
 
<div style="margin-left:1cm;margin-right:1cm;">Prior to 0.7.14 SSL could not be enabled selectively for individual listening sockets, as shown above. SSL could only be enabled for the entire server using the [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl ssl] directive, making it impossible to set up a single HTTP/HTTPS server. The <tt>ssl</tt> parameter of the [https://nginx.org/en/docs/http/ngx_http_core_module.html#listen listen] directive was added to solve this issue. The use of the [https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl ssl] directive in modern versions is thus discouraged; it was removed in 1.25.1. </div>
 
== Name-based HTTPS servers ==
 
A common issue arises when configuring two or more HTTPS servers listening on a single IP address:


== Namensbasierte HTTPS-Server ==
Ein häufiges Problem tritt auf, wenn zwei oder mehr HTTPS-Server konfiguriert werden, die auf einer einzigen IP-Adresse lauschen
<syntaxhighlight lang="nginx" highlight="" line copy>
server {
server {
    listen         443 ssl;
listen 443 ssl;
    server_name     www.example.com;
server_name www.example.com;
    ssl_certificate www.example.com.crt;
ssl_certificate www.example.com.crt;
    ...
[…]
}
}


server {
server {
    listen         443 ssl;
listen 443 ssl;
    server_name     www.example.org;
server_name www.example.org;
    ssl_certificate www.example.org.crt;
ssl_certificate www.example.org.crt;
    ...
[…]
}
}
</syntaxhighlight>


With this configuration a browser receives the default server’s certificate, i.e. <tt>www.example.com</tt> regardless of the requested server name. This is caused by SSL protocol behaviour. The SSL connection is established before the browser sends an HTTP request and nginx does not know the name of the requested server. Therefore, it may only offer the default server’s certificate.
Mit dieser Konfiguration erhält ein Browser das Standard-Serverzertifikat, d. h. <tt>www.example.com</tt>, unabhängig vom angeforderten Servernamen
* Dies wird durch das Verhalten des SSL-Protokolls verursacht
* Die SSL-Verbindung wird hergestellt, bevor der Browser eine HTTP-Anfrage sendet, und nginx kennt den Namen des angeforderten Servers nicht
* Daher kann es nur das Standard-Serverzertifikat anbieten


The oldest and most robust method to resolve the issue is to assign a separate IP address for every HTTPS server:
Die älteste und robusteste Methode zur Behebung des Problems besteht darin, jedem HTTPS-Server eine separate IP-Adresse zuzuweisen


<syntaxhighlight lang="nginx" highlight="" line copy>
server {
server {
    listen         192.168.1.1:443 ssl;
listen 192.168.1.1:443 ssl;
    server_name     www.example.com;
server_name www.example.com;
    ssl_certificate www.example.com.crt;
ssl_certificate www.example.com.crt;
    ...
..
}
}


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


=== An SSL certificate with several names ===
=== Zertifikat mit mehreren Namen ===
Es gibt andere Möglichkeiten, eine einzelne IP-Adresse zwischen mehreren HTTPS-Servern zu teilen
* Allerdings haben alle ihre Nachteile
* Eine Möglichkeit besteht darin, ein Zertifikat mit mehreren Namen im Zertifikatsfeld „SubjectAltName“ zu verwenden, zum Beispiel <tt>www.example.com</tt> und <tt>www.example.org</tt>
* Allerdings ist die Länge des Feldes „SubjectAltName“ begrenzt


There are other ways that allow sharing a single IP address between several HTTPS servers. However, all of them have their drawbacks. One way is to use a certificate with several names in the SubjectAltName certificate field, for example, <tt>www.example.com</tt> and <tt>www.example.org</tt>. However, the SubjectAltName field length is limited.  
Eine andere Möglichkeit besteht darin, ein Zertifikat mit einem Platzhalternamen zu verwenden, zum Beispiel <tt><nowiki>*.example.org</nowiki></tt>
* Ein Platzhalterzertifikat sichert alle Subdomains der angegebenen Domain, jedoch nur auf einer Ebene
* Dieses Zertifikat passt zu <tt>www.example.org</tt>, aber nicht zu <tt>example.org</tt> und <tt>www.sub.example.org</tt>
* Diese beiden Methoden können auch kombiniert werden
* Ein Zertifikat kann im Feld „SubjectAltName“ exakte Namen und Platzhalternamen enthalten, z. B. <tt>example.org</tt> und <tt><nowiki>*.example.org</nowiki></tt>


Another way is to use a certificate with a wildcard name, for example, <tt><nowiki>*.example.org</nowiki></tt>. A wildcard certificate secures all subdomains of the specified domain, but only on one level. This certificate matches <tt>www.example.org</tt>, but does not match <tt>example.org</tt> and <tt>www.sub.example.org</tt>. These two methods can also be combined. A certificate may contain exact and wildcard names in the SubjectAltName field, for example, <tt>example.org</tt> and <tt><nowiki>*.example.org</nowiki></tt>.
Es ist besser, eine Zertifikatsdatei mit mehreren Namen und ihre private Schlüsseldatei auf der HTTP-Ebene der Konfiguration zu platzieren, damit ihre einzelne Speicherkopie von allen Servern übernommen wird
 
<syntaxhighlight lang="nginx" highlight="" line copy>
It is better to place a certificate file with several names and its private key file at the http level of configuration to inherit their single memory copy in all servers:
ssl_certificate common.crt;
 
ssl_certificate     common.crt;
ssl_certificate_key common.key;
ssl_certificate_key common.key;


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


server {
server {
    listen         443 ssl;
listen 443 ssl;
    server_name     www.example.org;
server_name www.example.org;
    ...
..
}
}
</syntaxhighlight>


=== Server Name Indication ===
=== Server Name Indication ===
Eine allgemeinere Lösung für den Betrieb mehrerer HTTPS-Server unter einer einzigen IP-Adresse ist die [http://en.wikipedia.org/wiki/Server_Name_Indication TLS Server Name Indication-Erweiterung] (SNI, RFC 6066), die es einem Browser ermöglicht, während des SSL-Handshakes einen angeforderten Servernamen zu übermitteln, sodass der Server weiß, welches Zertifikat er für die Verbindung verwenden soll
* SNI wird derzeit von den meisten modernen Browsern [http://en.wikipedia.org/wiki/Server_Name_Indication#Support unterstützt] und ist eine obligatorische Erweiterung in TLSv1.3, die jedoch von einigen alten oder speziellen Clients möglicherweise nicht verwendet wird


A more generic solution for running several HTTPS servers on a single IP address is [http://en.wikipedia.org/wiki/Server_Name_Indication TLS Server Name Indication extension] (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently [http://en.wikipedia.org/wiki/Server_Name_Indication#Support supported] by most modern browsers and is a mandatory-to-implement extension in TLSv1.3, though may not be used by some old or special clients.
<div style="margin-left:1cm;margin-right:1cm;">In SNI können nur Domainnamen übergeben werden, jedoch können einige Browser fälschlicherweise eine IP-Adresse des Servers als dessen Namen übergeben, wenn eine Anfrage eine literale IP-Adresse enthält
* Man sollte sich nicht darauf verlassen. </div>


<div style="margin-left:1cm;margin-right:1cm;">Only domain names can be passed in SNI, however some browsers may erroneously pass an IP address of the server as its name if a request includes literal IP address. One should not rely on this. </div>
Um SNI in nginx verwenden zu können, muss es sowohl in der OpenSSL-Bibliothek, mit der die nginx-Binärdatei erstellt wurde, als auch in der Bibliothek, mit der es zur Laufzeit dynamisch verknüpft ist, unterstützt werden
* OpenSSL unterstützt SNI seit Version 0.9.8f, wenn es mit der Konfigurationsoption „--enable-tlsext” erstellt wurde
* Seit OpenSSL 0.9.8j ist diese Option standardmäßig aktiviert
* Wenn nginx mit SNI-Unterstützung erstellt wurde, zeigt nginx dies an, wenn es mit dem Schalter „-V” ausgeführt wird


In order to use SNI in nginx, it must be supported in both the OpenSSL library with which the nginx binary has been built as well as the library to which it is being dynamically linked at run time. OpenSSL supports SNI since 0.9.8f version if it was built with config option “--enable-tlsext”. Since OpenSSL 0.9.8j this option is enabled by default. If nginx was built with SNI support, then nginx will show this when run with the “-V” switch:
<syntaxhighlight lang="nginx" highlight="1" line copy>
nginx -V
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="" line>
..
TLS SNI-Unterstützung aktiviert
..
</syntaxhighlight>


$ nginx -V
Wenn jedoch das SNI-fähige nginx dynamisch mit einer OpenSSL-Bibliothek ohne SNI-Unterstützung verknüpft ist, zeigt nginx die folgende Warnung an
...
<syntaxhighlight lang="bash" highlight="" line>
TLS SNI support enabled
nginx wurde mit SNI-Unterstützung kompiliert, ist jedoch jetzt
...
dynamisch mit einer OpenSSL-Bibliothek verknüpft, die keine tlsext-Unterstützung bietet,
weshalb SNI nicht verfügbar ist
</syntaxhighlight>


However, if the SNI-enabled nginx is linked dynamically to an OpenSSL library without SNI support, nginx displays the warning:  
== Konfiguration ==
=== Dateien ===
{| class="wikitable options big"
|-
! Datei !! Beschreibung
|-
| ||
|-
| ||
|}
 
<noinclude>
 
== Anhang ==
=== Siehe auch ===
<div style="column-count:2">
<categorytree hideroot=on mode="pages">Nginx</categorytree>
</div>
----
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}


nginx was built with SNI support, however, now it is linked
=== Dokumentation ===
dynamically to an OpenSSL library which has no tlsext support,
# https://nginx.org/en/docs/http/configuring_https_servers.html
therefore SNI is not available
<!--
; Man-Page
# [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)]


=== Compatibility ===
; Info-Pages
-->


* The SNI support status has been shown by the “-V” switch since 0.8.21 and 0.7.62.
=== Links ===
* The <tt>ssl</tt> parameter of the [https://nginx.org/en/docs/http/ngx_http_core_module.html#listen listen] directive has been supported since 0.7.14. Prior to 0.8.21 it could only be specified along with the <tt>default</tt> parameter.
==== Projekt ====
* SNI has been supported since 0.5.23.
==== Weblinks ====
* The shared SSL session cache has been supported since 0.5.6.


* Version 1.27.3 and later: the default SSL protocols are TLSv1.2 and TLSv1.3 (if supported by the OpenSSL library). Otherwise, when OpenSSL 1.0.0 or older is used, the default SSL protocols are TLSv1 and TLSv1.1.
{{DEFAULTSORT:nginx/https}}
* Version 1.23.4 and later: the default SSL protocols are TLSv1, TLSv1.1, TLSv1.2, and TLSv1.3 (if supported by the OpenSSL library).
{{DISPLAYTITLE:nginx/https}}
* Version 1.9.1 and later: the default SSL protocols are TLSv1, TLSv1.1, and TLSv1.2 (if supported by the OpenSSL library).
* Version 0.7.65, 0.8.19 and later: the default SSL protocols are SSLv3, TLSv1, TLSv1.1, and TLSv1.2 (if supported by the OpenSSL library).
* Version 0.7.64, 0.8.18 and earlier: the default SSL protocols are SSLv2, SSLv3, and TLSv1.


* Version 1.0.5 and later: the default SSL ciphers are “<tt>HIGH:!aNULL:!MD5</tt>”.
* Version 0.7.65, 0.8.20 and later: the default SSL ciphers are “<tt>HIGH:!ADH:!MD5</tt>”.
* Version 0.8.19: the default SSL ciphers are “<tt>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM</tt>”.
* Version 0.7.64, 0.8.18 and earlier: the default SSL ciphers are“<tt>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</tt>”.
[[Kategorie:Nginx]]
[[Kategorie:Nginx]]
</noinclude>

Aktuelle Version vom 12. Oktober 2025, 12:44 Uhr

nginx/https - Konfigurieren von HTTPS-Servern

Beschreibung

HTTPS-Server konfigurieren

Beispiel 

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.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
..
}
Das Serverzertifikat ist eine öffentliche Entität
  • Es wird an jeden Client gesendet, der sich mit dem Server verbindet
  • Der private Schlüssel ist eine sichere Entität und sollte in einer Datei mit eingeschränktem Zugriff gespeichert werden, muss jedoch für den Master-Prozess von nginx lesbar sein
Der private Schlüssel kann alternativ in derselben Datei wie das Zertifikat gespeichert werden
ssl_certificate www.example.com.cert;
ssl_certificate_key www.example.com.cert;
Dateizugriffsrechte

In diesem Fall sollten auch die Dateizugriffsrechte eingeschränkt werden

  • Obwohl das Zertifikat und der Schlüssel in einer Datei gespeichert sind, wird nur das Zertifikat an einen Client gesendet
Direktiven

Mit den Direktiven ssl_protocols und ssl_ciphers ssl_ciphers können verwendet werden, um Verbindungen so zu beschränken, dass nur die starken Versionen und Verschlüsselungen von SSL/TLS zugelassen werden

  • Standardmäßig verwendet nginx „ssl_protocols TLSv1.2 TLSv1.3” und „ssl_ciphers HIGH:!aNULL:! MD5”, sodass eine explizite Konfiguration in der Regel nicht erforderlich ist
  • Beachten Sie, dass die Standardwerte dieser Direktiven mehrmals geändert wurden [1]

HTTPS-Serveroptimierung

SSL-Operationen verbrauchen zusätzliche CPU-Ressourcen

Auf Multiprozessorsystemen sollten mehrere Worker-Prozesse ausgeführt werden, mindestens jedoch so viele wie die Anzahl der verfügbaren CPU-Kerne

  • Der CPU-intensivste Vorgang ist der SSL-Handshake
  • Es gibt zwei Möglichkeiten, die Anzahl dieser Vorgänge pro Client zu minimieren: Die erste besteht darin, Keepalive-Verbindungen zu aktivieren, um mehrere Anfragen über eine Verbindung zu senden, und die zweite darin, SSL-Sitzungsparameter wiederzuverwenden, um SSL-Handshakes für parallele und nachfolgende Verbindungen zu vermeiden
  • Die Sitzungen werden in einem SSL-Sitzungscache gespeichert, der von den Arbeitern gemeinsam genutzt und durch die Direktive ssl_session_cache konfiguriert wird
  • Ein Megabyte des Caches enthält etwa 4000 Sitzungen
  • Die Standard-Cache-Zeitüberschreitung beträgt 5 Minuten

Sie kann mit der Direktive ssl_session_timeout erhöht werden

Hier ist eine Beispielkonfiguration, die für ein Multi-Core-System mit einem gemeinsam genutzten 10-Megabyte-Sitzungscache optimiert ist 

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

Zertifikatsketten

Einige Browser melden möglicherweise Fehler bei einem Zertifikat, das von einer bekannten Zertifizierungsstelle signiert wurde, während andere Browser das Zertifikat ohne Probleme akzeptieren

  • Dies geschieht, weil die ausstellende Stelle das Serverzertifikat mit einem Zwischenzertifikat signiert hat, das nicht in der Zertifikatsdatenbank der bekannten vertrauenswürdigen Zertifizierungsstellen enthalten ist, die mit einem bestimmten Browser verteilt wird
  • In diesem Fall stellt die Stelle ein Bündel verketteter Zertifikate bereit, die an das signierte Serverzertifikat angehängt werden sollten

Das Serverzertifikat muss in der kombinierten Datei vor den verketteten Zertifikaten erscheinen 

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

Die resultierende Datei sollte in der Anweisung ssl_certificate verwendet werden 

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

Wenn das Serverzertifikat und das Bundle in der falschen Reihenfolge verkettet wurden, kann nginx nicht gestartet werden und zeigt die folgende Fehlermeldung an 

SSL_CTX_use_PrivateKey_file(„ ... /www.example.com.key“) fehlgeschlagen
(SSL: Fehler:05800074:x509 Zertifikatsroutinen::Schlüsselwerte stimmen nicht überein)

da nginx versucht hat, den privaten Schlüssel mit dem ersten Zertifikat des Bundles anstelle des Serverzertifikats zu verwenden

Zwischenzertifikate

Browser speichern in der Regel Zwischenzertifikate, die sie erhalten und die von vertrauenswürdigen Stellen signiert sind

  • Daher verfügen aktiv genutzte Browser möglicherweise bereits über die erforderlichen Zwischenzertifikate und melden keine Fehler, wenn ein Zertifikat ohne verkettetes Bundle gesendet wird
  • Um sicherzustellen, dass der Server die vollständige Zertifikatskette sendet, kann das Befehlszeilenprogramm openssl verwendet werden
Beispiel
openssl s_client -connect www.godaddy.com:443

..
Zertifikatskette
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, Klausel 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 wird

  • das Subjekt („s“) des www. GoDaddy.com-Serverzertifikats Nr. 0 von einem Aussteller („i“) signiert, der selbst das Subjekt des Zertifikats Nr. 1 ist, das von einem Aussteller signiert wurde, der selbst das Subjekt des Zertifikats Nr. 2 ist, das von dem bekannten Aussteller ValiCert, Inc. signiert wurde, dessen Zertifikat in der integrierten Zertifikatsdatenbank des Browsers gespeichert ist (die in dem Haus lag, das Jack gebaut hatte)

Wenn kein Zertifikatspaket hinzugefügt wurde, wird nur das Serverzertifikat Nr. 0 angezeigt

Einzelner Server

Ein einzelner HTTP/HTTPS-Server

Es ist möglich, einen einzelnen Server zu konfigurieren, der sowohl HTTP- als auch HTTPS-Anfragen verarbeitet 

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 0.7.14 konnte SSL nicht selektiv für einzelne Listening-Sockets aktiviert werden, wie oben gezeigt

  • SSL konnte nur für den gesamten Server mit der Anweisung ssl aktiviert werden, wodurch es unmöglich war, einen einzelnen HTTP/HTTPS-Server einzurichten
  • Der Parameter ssl der Anweisung listen wurde hinzugefügt, um dieses Problem zu beheben
  • Die Verwendung der Direktive ssl in modernen Versionen wird daher nicht empfohlen; sie wurde in 1.25.1 entfernt

Namensbasierte HTTPS-Server

Ein häufiges Problem tritt auf, wenn zwei oder mehr HTTPS-Server konfiguriert werden, die auf einer einzigen IP-Adresse lauschen 

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;
[…]
}

Mit dieser Konfiguration erhält ein Browser das Standard-Serverzertifikat, d. h. www.example.com, unabhängig vom angeforderten Servernamen

  • Dies wird durch das Verhalten des SSL-Protokolls verursacht
  • Die SSL-Verbindung wird hergestellt, bevor der Browser eine HTTP-Anfrage sendet, und nginx kennt den Namen des angeforderten Servers nicht
  • Daher kann es nur das Standard-Serverzertifikat anbieten

Die älteste und robusteste Methode zur Behebung des Problems besteht darin, jedem HTTPS-Server eine separate IP-Adresse zuzuweisen 

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;
..
}

Zertifikat mit mehreren Namen

Es gibt andere Möglichkeiten, eine einzelne IP-Adresse zwischen mehreren HTTPS-Servern zu teilen

  • Allerdings haben alle ihre Nachteile
  • Eine Möglichkeit besteht darin, ein Zertifikat mit mehreren Namen im Zertifikatsfeld „SubjectAltName“ zu verwenden, zum Beispiel www.example.com und www.example.org
  • Allerdings ist die Länge des Feldes „SubjectAltName“ begrenzt

Eine andere Möglichkeit besteht darin, ein Zertifikat mit einem Platzhalternamen zu verwenden, zum Beispiel *.example.org

  • Ein Platzhalterzertifikat sichert alle Subdomains der angegebenen Domain, jedoch nur auf einer Ebene
  • Dieses Zertifikat passt zu www.example.org, aber nicht zu example.org und www.sub.example.org
  • Diese beiden Methoden können auch kombiniert werden
  • Ein Zertifikat kann im Feld „SubjectAltName“ exakte Namen und Platzhalternamen enthalten, z. B. example.org und *.example.org

Es ist besser, eine Zertifikatsdatei mit mehreren Namen und ihre private Schlüsseldatei auf der HTTP-Ebene der Konfiguration zu platzieren, damit ihre einzelne Speicherkopie von allen Servern übernommen wird 

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 Indication

Eine allgemeinere Lösung für den Betrieb mehrerer HTTPS-Server unter einer einzigen IP-Adresse ist die TLS Server Name Indication-Erweiterung (SNI, RFC 6066), die es einem Browser ermöglicht, während des SSL-Handshakes einen angeforderten Servernamen zu übermitteln, sodass der Server weiß, welches Zertifikat er für die Verbindung verwenden soll

  • SNI wird derzeit von den meisten modernen Browsern unterstützt und ist eine obligatorische Erweiterung in TLSv1.3, die jedoch von einigen alten oder speziellen Clients möglicherweise nicht verwendet wird
In SNI können nur Domainnamen übergeben werden, jedoch können einige Browser fälschlicherweise eine IP-Adresse des Servers als dessen Namen übergeben, wenn eine Anfrage eine literale IP-Adresse enthält
  • Man sollte sich nicht darauf verlassen.

Um SNI in nginx verwenden zu können, muss es sowohl in der OpenSSL-Bibliothek, mit der die nginx-Binärdatei erstellt wurde, als auch in der Bibliothek, mit der es zur Laufzeit dynamisch verknüpft ist, unterstützt werden

  • OpenSSL unterstützt SNI seit Version 0.9.8f, wenn es mit der Konfigurationsoption „--enable-tlsext” erstellt wurde
  • Seit OpenSSL 0.9.8j ist diese Option standardmäßig aktiviert
  • Wenn nginx mit SNI-Unterstützung erstellt wurde, zeigt nginx dies an, wenn es mit dem Schalter „-V” ausgeführt wird
nginx -V

..
TLS SNI-Unterstützung aktiviert
..

Wenn jedoch das SNI-fähige nginx dynamisch mit einer OpenSSL-Bibliothek ohne SNI-Unterstützung verknüpft ist, zeigt nginx die folgende Warnung an 

nginx wurde mit SNI-Unterstützung kompiliert, ist jedoch jetzt
dynamisch mit einer OpenSSL-Bibliothek verknüpft, die keine tlsext-Unterstützung bietet,
weshalb SNI nicht verfügbar ist

Konfiguration

Dateien

Datei Beschreibung


Anhang

Siehe auch


Dokumentation

  1. https://nginx.org/en/docs/http/configuring_https_servers.html

Links

Projekt

Weblinks


Abgerufen von „https://wiki.foxtom.de/index.php?title=Nginx/https&oldid=154901“