Auf dieser Seite finden Sie eine Anleitung zum Einrichten von HTTPS auf Ihren Servern. Dazu gehören die folgenden Schritte:
- Erstellen Sie ein öffentliches/privates RSA-Schlüsselpaar mit 2.048 Bit.
- Generieren Sie eine CSR-Anfrage (Certificate Signing Request), die Ihren öffentlichen Schlüssel enthält.
- Sie geben Ihre CSR an die Zertifizierungsstelle weiter, um ein endgültiges Zertifikat oder eine Zertifikatskette zu erhalten.
- Installieren Sie das endgültige Zertifikat an einem nicht über das Web zugänglichen Ort, z. B. unter
/etc/ssl(Linux und Unix) oder an einem Ort, an dem es für IIS erforderlich ist (Windows).
Schlüssel und Anfragen zur Zertifikatsignatur generieren
In diesem Abschnitt wird das Befehlszeilentool „openssl“ verwendet, das im Lieferumfang der meisten Linux-, BSD- und Mac OS X-Systeme enthalten ist. Mit dem Tool werden private und öffentliche Schlüssel und eine CSR generiert.
Öffentliches/privates Schlüsselpaar generieren
Generieren Sie zuerst ein 2.048-Bit-RSA-Schlüsselpaar. Ein kürzerer Schlüssel kann durch Brute-Force-Angriffe geknackt werden und längere Schlüssel verbrauchen unnötige Ressourcen.
Verwenden Sie den folgenden Befehl, um ein RSA-Schlüsselpaar zu generieren:
openssl genrsa -out www.example.com.key 2048
Das ergibt folgende Ausgabe:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
Zertifikatsignatur-Anfrage generieren
In diesem Schritt betten Sie Ihren öffentlichen Schlüssel und Informationen zu Ihrer Organisation und Ihrer Website in eine CSR-Anfrage ein. Beim Befehl openssl werden Sie nach den erforderlichen Metadaten gefragt.
Führen Sie folgenden Befehl aus:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
Die Ausgabe sieht so aus:
You are about to be asked to enter information that will be incorporated
into your certificate request
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Führen Sie den folgenden Befehl aus, um die Gültigkeit des CSR zu prüfen:
openssl req -text -in www.example.com.csr -noout
Die Antwort sollte in etwa so aussehen:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
CSR bei einer Zertifizierungsstelle einreichen
Je nach Zertifizierungsstelle (Certificate Authority, CA) müssen Sie Ihre CSRs auf unterschiedliche Weise einreichen. Dazu kann ein Formular auf der Website oder das Senden der Antwortvorlage per E-Mail gehören. Einige Zertifizierungsstellen oder ihre Reseller automatisieren möglicherweise einen Teil oder den gesamten Prozess, einschließlich in einigen Fällen der Generierung von Schlüsselpaaren und CSRs.
Senden Sie den CSR an Ihre Zertifizierungsstelle und folgen Sie der Anleitung, um das endgültige Zertifikat oder die endgültige Zertifikatskette zu erhalten.
Die Kosten für die Bestätigung Ihres öffentlichen Schlüssels variieren je nach Zertifizierungsstelle.
Es gibt auch Optionen, Ihren Schlüssel mit mehreren DNS-Namen zu verknüpfen, einschließlich mehrerer verschiedener Namen (z.B. alle von beispiel.de, www.beispiel.de, beispiel.net und www.beispiel.net) oder Platzhalternamen wie *.example.com.
Kopieren Sie die Zertifikate an einen nicht über das Web zugänglichen Speicherort wie /etc/ssl (Linux und Unix) oder an einen Ort, an dem sie für IIS (Windows) erforderlich sind.
HTTPS auf Ihren Servern aktivieren
Die Aktivierung von HTTPS auf Ihren Servern ist ein wichtiger Schritt zur Gewährleistung der Sicherheit Ihrer Webseiten.
- Verwenden Sie das Serverkonfigurationstool von Mozilla, um Ihren Server für den HTTPS-Support einzurichten.
- Testen Sie Ihre Website regelmäßig mit dem SSL Server Test von Qualys und achten Sie darauf, dass Sie mindestens die Note „A“ oder „A+“ erhalten.
An dieser Stelle müssen Sie eine wichtige betriebliche Entscheidung treffen. Wählen Sie eine der folgenden Optionen aus:
- Weisen Sie jedem Hostnamen, von dem Ihr Webserver Inhalte bereitstellt, eine eindeutige IP-Adresse zu.
- Verwenden Sie namenbasiertes virtuelles Hosting.
Wenn Sie für jeden Hostnamen unterschiedliche IP-Adressen verwendet haben, können Sie sowohl HTTP als auch HTTPS für alle Clients unterstützen. Die meisten Website-Betreiber verwenden jedoch das namensbasierte virtuelle Hosting, um IP-Adressen zu sparen und weil es im Allgemeinen praktischer ist.
Wenn der HTTPS-Dienst auf Ihren Servern noch nicht verfügbar ist, aktivieren Sie ihn jetzt, ohne HTTP auf HTTPS weiterzuleiten. Weitere Informationen finden Sie unter HTTP-zu-HTTPS-Weiterleitung. Konfigurieren Sie Ihren Webserver so, dass er die von Ihnen gekauften und installierten Zertifikate verwendet. Der Konfigurationsgenerator von Mozilla kann hilfreich sein.
Wenn Sie viele Hostnamen oder Subdomains haben, muss für jeden das richtige Zertifikat verwendet werden.
Prüfen Sie jetzt und regelmäßig während der Lebensdauer Ihrer Website Ihre HTTPS-Konfiguration mit dem SSL-Servertest von Qualys. Ihre Website sollte die Note „A“ oder „A+“ erhalten. Behandeln Sie alles, was zu einer niedrigeren Note führt, als Fehler und bleiben Sie wachsam, da ständig neue Angriffe auf Algorithmen und Protokolle entwickelt werden.
Intrasite-URLs relativ machen
Da Sie Ihre Website jetzt sowohl über HTTP als auch über HTTPS bereitstellen, müssen die Abläufe unabhängig vom Protokoll möglichst reibungslos funktionieren. Ein wichtiger Faktor ist die Verwendung relativer URLs für Intra-Website-Links.
Achten Sie darauf, dass Intra-Site-URLs und externe URLs nicht von einem bestimmten Protokoll abhängen.
Verwenden Sie relative Pfade oder lassen Sie das Protokoll wie in //example.com/something.js aus.
Das Bereitstellen einer Seite mit HTTP-Ressourcen über HTTPS kann zu Problemen führen. Wenn ein Browser auf eine ansonsten sichere Seite mit unsicheren Ressourcen stößt, werden Nutzer gewarnt, dass die Seite nicht vollständig sicher ist. Einige Browser lehnen das Laden oder Ausführen der HTTP-Ressourcen ab, wodurch die Seite nicht angezeigt wird. Sie können jedoch HTTPS-Ressourcen auf einer HTTP-Seite einfügen. Weitere Informationen zur Behebung dieser Probleme finden Sie unter Mischinhalte beheben.
Wenn Sie HTTP-basierte Links zu anderen Seiten auf Ihrer Website folgen, kann die Nutzerfreundlichkeit von HTTPS zu HTTP herabgestuft werden. Um dieses Problem zu beheben, sollten Sie Ihre Intra-Site-URLs so relativ wie möglich gestalten. Sie können sie entweder protokollrelativ (ohne Protokoll, beginnend mit //example.com) oder hostrelativ (beginnend mit dem Pfad, z. B. /jquery.js) machen.
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p>Relative Intra-Site-URLs verwenden.
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>Alternativ können Sie protokollrelative Intra-Site-URLs verwenden.
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>Verwenden Sie nach Möglichkeit HTTPS-URLs für Links zu anderen Websites.
Aktualisieren Sie Ihre Links mit einem Script, nicht manuell, um Fehler zu vermeiden. Wenn sich die Inhalte Ihrer Website in einer Datenbank befinden, testen Sie Ihr Script an einer Entwicklungskopie der Datenbank. Wenn die Inhalte Ihrer Website nur aus einfachen Dateien bestehen, testen Sie Ihr Script an einer Entwicklungskopie der Dateien. Übertragen Sie die Änderungen wie gewohnt erst in die Produktion, nachdem sie die QA bestanden haben. Sie können das Script von Bram van Damme oder ein ähnliches Tool verwenden, um gemischte Inhalte auf Ihrer Website zu erkennen.
Wenn Sie auf andere Websites verlinken (anstatt Ressourcen von ihnen einzubinden), ändern Sie das Protokoll nicht. Sie haben keine Kontrolle darüber, wie diese Websites betrieben werden.
Für eine reibungslosere Migration bei großen Websites empfehlen wir protokollabstrakte URLs. Wenn Sie sich nicht sicher sind, ob Sie HTTPS bereits vollständig implementieren können, kann es sich als nachteilig erweisen, wenn Sie auf Ihrer Website HTTPS für alle Unterressourcen erzwingen. Es wird wahrscheinlich eine gewisse Zeit dauern, bis Sie mit HTTPS vertraut sind. Die HTTP-Website muss aber weiterhin wie gewohnt funktionieren. Im Laufe der Zeit schließen Sie die Migration ab und aktivieren HTTPS (siehe die nächsten beiden Abschnitte).
Wenn Ihre Website von Scripts, Bildern oder anderen Ressourcen von Drittanbietern abhängt, z. B. von einem CDN oder jquery.com, haben Sie zwei Möglichkeiten:
- Verwenden Sie für diese Ressourcen protokollrelative URLs. Wenn der Drittanbieter keine HTTPS-Verbindung bereitstellt, bitten Sie ihn darum. Die meisten tun dies bereits, einschließlich jquery.com.
- Stellen Sie die Ressourcen von einem von Ihnen verwalteten Server bereit, der sowohl HTTP als auch HTTPS unterstützt. Das ist oft ohnehin eine gute Idee, da Sie dann die Darstellung, Leistung und Sicherheit Ihrer Website besser im Blick haben und nicht auf einen Drittanbieter angewiesen sind, der Ihre Website sichert.
HTTP an HTTPS weiterleiten
Wenn Sie Suchmaschinen anweisen möchten, HTTPS für den Zugriff auf Ihre Website zu verwenden, fügen Sie am Anfang jeder Seite einen kanonischen Link mithilfe von <link rel="canonical" href="https://…"/>-Tags ein.
Strict Transport Security und sichere Cookies aktivieren
Jetzt können Sie die Verwendung von HTTPS festlegen:
- Verwenden Sie HTTP Strict Transport Security (HSTS), um die Kosten für die 301-Weiterleitung zu vermeiden.
- Setzen Sie bei Cookies immer das Flag „Secure“.
Verwenden Sie zuerst Strict Transport Security, um Clients anzuweisen, sich immer über HTTPS mit Ihrem Server zu verbinden, auch wenn sie einer http://-Referenz folgen. So werden Angriffe wie SSL-Entfernung verhindert und die Kosten für die Rückschleife der 301 redirect vermieden, die wir unter HTTP-zu-HTTPS-Weiterleitung aktiviert haben.
Wenn Sie HSTS aktivieren möchten, legen Sie den Strict-Transport-Security-Header fest. Auf der HSTS-Seite von OWASP finden Sie Links zu Anleitungen für verschiedene Arten von Serversoftware.
Die meisten Webserver bieten eine ähnliche Möglichkeit, benutzerdefinierte Header hinzuzufügen.
Außerdem ist es wichtig, dass Clients niemals Cookies (z. B. für die Authentifizierung oder Websiteeinstellungen) über HTTP senden. Wenn beispielsweise das Authentifizierungs-Cookie eines Nutzers im Klartext offengelegt wird, ist die Sicherheitsgarantie für die gesamte Sitzung ungültig, auch wenn Sie alles andere richtig gemacht haben.
Um dies zu vermeiden, sollten Sie in Ihrer Webanwendung das Flag „Secure“ (Sicher) für die von Ihnen festgelegten Cookies immer setzen. Auf dieser OWASP-Seite wird beschrieben, wie Sie das Flag „Secure“ in verschiedenen App-Frameworks festlegen. Jedes App-Framework bietet eine Möglichkeit, das Flag festzulegen.
Die meisten Webserver bieten eine einfache Weiterleitungsfunktion. Verwenden Sie 301 (Moved Permanently), um Suchmaschinen und Browsern anzugeben, dass die HTTPS-Version kanonisch ist, und leiten Sie Ihre Nutzer von HTTP zur HTTPS-Version Ihrer Website weiter.
Suchranking
Google betrachtet HTTPS als positiven Indikator für die Qualität der Suche. Google veröffentlicht außerdem eine Anleitung dazu, wie Sie Ihre Website übertragen, verschieben oder migrieren, ohne dass sich der Suchrang ändert. Bing veröffentlicht außerdem Richtlinien für Webmaster.
Leistung
Wenn die Inhalts- und Anwendungsebenen gut abgestimmt sind (weitere Informationen finden Sie in den Büchern von Steve Souders), sind die verbleibenden TLS-Leistungsprobleme im Vergleich zu den Gesamtkosten der Anwendung in der Regel gering. Sie können diese Kosten auch senken und abschreiben. Informationen zur TLS-Optimierung finden Sie in High Performance Browser Networking von Ilya Grigorik sowie in OpenSSL Cookbook und Bulletproof SSL And TLS von Ivan Ristic.
In einigen Fällen kann TLS die Leistung verbessern, vor allem weil dadurch HTTP/2 möglich wird. Weitere Informationen finden Sie im Vortrag von Chris Palmer zur HTTPS- und HTTP/2-Leistung beim Chrome Dev Summit 2014.
Referer-Header
Wenn Nutzer Links von Ihrer HTTPS-Website zu anderen HTTP-Websites folgen, senden User-Agents den Referer-Header nicht. Es gibt mehrere Möglichkeiten, dieses Problem zu beheben:
- Die anderen Websites sollten auf HTTPS umgestellt werden. Wenn die Verweiswebsites den Abschnitt HTTPS auf Ihren Servern aktivieren in diesem Leitfaden ausführen, können Sie die Links auf Ihrer Website von
http://zuhttps://ändern oder protokollrelative Links verwenden. - Verwenden Sie den neuen Referrer-Policy-Standard, um eine Vielzahl von Problemen mit Referrer-Headern zu vermeiden.
Werbeeinnahmen
Betreiber von Websites, die ihre Website durch Anzeigen monetarisieren, möchten sicherstellen, dass die Anzeigenimpressionen durch die Migration zu HTTPS nicht sinken. Aufgrund von Sicherheitsbedenken im Zusammenhang mit gemischten Inhalten funktioniert eine HTTP-<iframe> jedoch nicht auf einer HTTPS-Seite.
Solange Werbetreibende nicht über HTTPS schalten, können Website-Betreiber nicht zu HTTPS migrieren, ohne Werbeeinnahmen zu verlieren. Solange Website-Betreiber nicht zu HTTPS migrieren, haben Werbetreibende wenig Motivation, Anzeigen über HTTPS zu schalten.
Sie können diesen Stillstand durch die Zusammenarbeit mit Werbetreibenden beenden, die Anzeigendienste über HTTPS anbieten, und Werbetreibende, die keine HTTPS-Anzeigen ausliefern, bitten, dies zumindest als Option anzubieten. Möglicherweise müssen Sie die Option Intra-Website-URLs relativ machen erst aktivieren, wenn genügend Werbetreibende die korrekte Interoperabilität erreicht haben.