HTTPS auf Ihren Servern aktivieren

Chris Palmer
Chris Palmer
Matt Gaunt

In diesem Artikel behandelte Schritte

  1. Erstellen Sie ein 2048-Bit-RSA-Schlüsselpaar mit öffentlichem und privatem Schlüssel.
  2. Generieren Sie eine Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR), in die Ihr öffentlicher Schlüssel eingebettet ist.
  3. Teilen Sie Ihre CSR mit Ihrer Zertifizierungsstelle, um ein endgültiges Zertifikat oder eine Zertifikatskette zu erhalten.
  4. Installieren Sie das endgültige Zertifikat an einem Ort, der nicht über das Web zugänglich ist, z. B. /etc/ssl (Linux und Unix) oder wo immer IIS es erfordert (Windows).

Schlüssel und Anfragen zur Zertifikatsignierung generieren

In diesem Abschnitt wird das Befehlszeilenprogramm openssl verwendet, das im Lieferumfang der meisten Linux-, BSD- und Mac OS X-Systeme enthalten ist, um private/öffentliche Schlüssel und eine CSR zu generieren.

Generieren Sie ein öffentliches/privates Schlüsselpaar

Beginnen wir mit einem 2.048-Bit-RSA-Schlüsselpaar. Ein kleinerer Schlüssel wie 1.024 Bit ist nicht ausreichend gegen Brute-Force-Angriffe geschützt. Ein größerer Schlüssel wie 4.096 Bit ist Overkill. Mit der Zeit nehmen die Schlüsselgrößen zu, da die Computerverarbeitung immer günstiger wird. 2.048 ist derzeit die beste Wahl.

Der Befehl zum Generieren des RSA-Schlüsselpaars lautet:

openssl genrsa -out www.example.com.key 2048

Dadurch ergibt sich folgende Ausgabe:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Anfrage zur Zertifikatssignierung generieren

In diesem Schritt betten Sie Ihren öffentlichen Schlüssel und Informationen über Ihre Organisation und Ihre Website in eine Zertifikatsignierungsanfrage oder CSR ein. Der Befehl openssl fragt Sie interaktiv nach den erforderlichen Metadaten.

Führen Sie folgenden Befehl aus:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

Gibt Folgendes 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 []:

Um die Gültigkeit der CSR zu bestätigen, führen Sie den folgenden Befehl aus:

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 Authorities, CAs) sind unterschiedliche Methoden zum Senden Ihrer CSRs erforderlich. Möglich ist z. B. die Verwendung eines Formulars auf der Website oder das Senden der CSR per E-Mail. Einige Zertifizierungsstellen (oder ihre Reseller) automatisieren möglicherweise einen Teil oder den gesamten Prozess (in manchen Fällen auch das Generieren von Schlüsselpaaren und CSR).

Senden Sie die CSR an Ihre Zertifizierungsstelle und folgen Sie deren Anweisungen, um Ihr endgültiges Zertifikat oder Ihre Zertifikatskette zu erhalten.

Verschiedene Zertifizierungsstellen berechnen unterschiedliche Beträge für den Dienst, mit dem Sie Ihren öffentlichen Schlüssel authentifizieren können.

Es gibt auch Optionen, um Ihren Schlüssel mehr als einem DNS-Namen zuzuordnen, einschließlich verschiedener unterschiedlicher Namen (z.B. alle beispiel.de, www.beispiel.de, beispiel.net und www.beispiel.net) oder „Platzhalter“-Namen wie *.beispiel.de.

Beispielsweise bietet eine Zertifizierungsstelle derzeit folgende Preise an:

  • Standard: 16 $/Jahr, gültig für beispiel.de und www.beispiel.de.
  • Platzhalter: 150 $/Jahr, gültig für beispiel.de und *.beispiel.de.

In diesen Preisen sind Platzhalterzertifikate kostengünstig, wenn Sie mehr als 9 Subdomains haben. Andernfalls können Sie einfach ein oder mehrere Zertifikate mit einem Namen kaufen. Wenn Sie beispielsweise mehr als fünf Subdomains haben, finden Sie ein Platzhalterzertifikat möglicherweise praktischer, wenn Sie HTTPS auf Ihren Servern aktivieren.

Kopieren Sie die Zertifikate auf alle Frontend-Server an einem nicht über das Web zugänglichen Ort wie /etc/ssl (Linux und Unix) oder wo immer IIS (Windows) sie erfordert.

HTTPS auf Ihren Servern aktivieren

Das Aktivieren von HTTPS auf Ihren Servern ist ein wichtiger Schritt, um die Sicherheit Ihrer Webseiten zu gewährleisten.

  • Verwenden Sie das Serverkonfigurationstool von Mozilla, um Ihren Server für die HTTPS-Unterstützung einzurichten.
  • Testen Sie Ihre Website regelmäßig mit dem praktischen SSL-Servertest von Qualys und achten Sie darauf, dass Sie mindestens ein A oder A+ erhalten.

An dieser Stelle müssen Sie eine wichtige operative Entscheidung treffen. Wählen Sie eine der folgenden Optionen aus:

  • Weisen Sie jedem Hostnamen, für den Ihr Webserver Inhalte bereitstellt, eine eigene IP-Adresse zu.
  • Verwenden Sie Namensbasiertes virtuelles Hosting.

Wenn Sie für jeden Hostnamen unterschiedliche IP-Adressen verwendet haben, können Sie für alle Clients ganz einfach sowohl HTTP als auch HTTPS unterstützen.

Die meisten Websitebetreiber verwenden jedoch Namensbasiertes virtuelles Hosting, um IP-Adressen zu sparen und weil dies im Allgemeinen praktischer ist. Das Problem mit Internet Explorer (IE) unter Windows XP und Android vor Version 2.3 ist, dass er Server Name Indication (SNI) nicht versteht. Diese Funktion ist für das name-basierte HTTPS-Hosting virtueller Hosts sehr wichtig.

Irgendwann – hoffentlich bald – werden Clients, die SNI nicht unterstützen, durch moderne Software ersetzt. Überwachen Sie den User-Agent-String in Ihren Anfragelogs, um festzustellen, wann genügend Nutzer zu moderner Software migriert sind. Sie können Ihren Grenzwert auch selbst bestimmen. Dieser kann eventuell weniger als 5 % oder weniger als 1 % betragen.

Wenn der HTTPS-Dienst noch nicht auf Ihren Servern verfügbar ist, aktivieren Sie ihn jetzt (ohne Weiterleitung von HTTP zu HTTPS, siehe unten). Konfigurieren Sie Ihren Webserver so, dass die erworbenen und installierten Zertifikate verwendet werden. Dafür könnte der praktische Konfigurationsgenerator von Mozilla hilfreich sein.

Wenn Sie viele Hostnamen oder Subdomains haben, muss für jede das richtige Zertifikat verwendet werden.

Überprüfen Sie jetzt und während der gesamten Lebensdauer Ihrer Website Ihre HTTPS-Konfiguration mit dem SSL-Servertest von Qualys. Ihre Website sollte mit A oder A+ bewertet werden. Behandeln Sie alles, was eine niedrigere Bewertung verursacht, als Fehler. (Das heutige A ist das B von morgen, weil Angriffe auf Algorithmen und Protokolle immer besser werden.)

Website-interne URLs relativ einrichten

Da Ihre Website nun sowohl über HTTP als auch über HTTPS bereitgestellt wird, muss alles unabhängig vom Protokoll so reibungslos wie möglich funktionieren. Ein wichtiger Faktor ist die Verwendung von relativen URLs für Intrasite-Links.

Achten Sie darauf, dass websiteinterne und externe URLs protokollunabhängig sind. Verwenden Sie also relative Pfade oder lassen Sie das Protokoll wie //example.com/something.js weg.

Ein Problem tritt auf, wenn Sie eine Seite über HTTPS bereitstellen, die HTTP-Ressourcen enthält, die als gemischte Inhalte bezeichnet werden. Browser warnen Nutzer, dass die volle Stärke von HTTPS verloren gegangen ist. Bei aktiven gemischten Inhalten (Script, Plug-ins, CSS, iFrames) laden Browser häufig die Inhalte gar nicht oder führen sie nicht aus, was zu einer fehlerhaften Seite führt. Außerdem ist es völlig in Ordnung, HTTPS-Ressourcen in eine HTTP-Seite aufzunehmen.

Wenn Sie auf andere Seiten Ihrer Website verlinken, kann es außerdem passieren, dass ein Downgrade von HTTPS auf HTTP für Nutzer erfolgt.

Diese Probleme treten auf, wenn Ihre Seiten vollständig qualifizierte, websiteinterne URLs mit dem Schema http:// enthalten.

Don'ts
<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
Verwenden Sie keine voll qualifizierten URLs innerhalb der Website.

Mit anderen Worten: Machen Sie Website-interne URLs so relativ wie möglich: entweder protokollrelative (fehlendes Protokoll, beginnend mit //example.com) oder Hostrelativ (beginnend nur mit dem Pfad, z. B. /jquery.js).

Das sollten Sie tun:
<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>
Verwenden Sie relative URLs innerhalb der Website.
Das sollten Sie tun:
<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 URLs innerhalb der Website verwenden.
Das sollten Sie tun:
<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 intersite-URLs.

Das geht mit einem Skript, nicht von Hand. Wenn sich der Inhalt Ihrer Website in einer Datenbank befindet, testen Sie das Skript an einer Entwicklungskopie Ihrer Datenbank. Wenn der Inhalt Ihrer Website aus einfachen Dateien besteht, testen Sie Ihr Skript an einer Entwicklungskopie der Dateien. Übertragen Sie die Änderungen wie gewohnt erst in die Produktion, wenn die Änderungen die QA bestanden haben. Sie können das Skript von Bram van Damme oder etwas Ähnliches verwenden, um gemischte Inhalte auf Ihrer Website zu erkennen.

Wenn Sie auf andere Websites verlinken (anstatt Ressourcen von diesen Websites einzuschließen), ändern Sie das Protokoll nicht, da Sie keine Kontrolle über die Funktionsweise dieser Websites haben.

Für eine reibungslosere Migration großer Websites empfehlen wir protokollrelative URLs. Wenn Sie sich nicht sicher sind, ob Sie HTTPS noch nicht vollständig bereitstellen können, kann die Verwendung von HTTPS für alle Unterressourcen nach hinten starten. Es wird wahrscheinlich einige Zeit geben, in der HTTPS neu und seltsam für Sie ist und die HTTP-Website weiterhin wie gewohnt funktionieren muss. Im Laufe der Zeit schließen Sie die Migration ab und setzen HTTPS ein (siehe die nächsten beiden Abschnitte).

Wenn Ihre Website von Skripts, Bildern oder anderen Ressourcen abhängig ist, die von einem Drittanbieter wie CDN oder jquery.com bereitgestellt werden, haben Sie zwei Möglichkeiten:

  • Verwenden Sie für diese Ressourcen protokollrelative URLs. Wenn der Drittanbieter kein HTTPS 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 bietet. Dies ist sowieso oft eine gute Idee, da Sie dann das Erscheinungsbild, die Leistung und die Sicherheit Ihrer Website besser kontrollieren können. Außerdem müssen Sie keinem Drittanbieter vertrauen, was immer hilfreich ist.

HTTP zu HTTPS weiterleiten

Du musst im Header deiner Seite einen kanonischen Link einfügen, um Suchmaschinen darüber zu informieren, dass HTTPS der beste Weg ist, um zu deiner Website zu gelangen.

Legen Sie <link rel="canonical" href="https://…"/>-Tags auf Ihren Seiten fest. So können Suchmaschinen leichter ermitteln, wie sie am besten zu Ihrer Website gelangen.

Strict Transport Security und sichere Cookies aktivieren

Jetzt können Sie die Verwendung von HTTPS „festlegen“.

  • Verwende HTTP Strict Transport Security (HSTS), um die Kosten der 301-Weiterleitung zu vermeiden.
  • Bei Cookies immer das Sicherheits-Flag setzen.

Verwenden Sie zuerst Strict Transport Security, um Clients mitzuteilen, dass sie sich immer über HTTPS mit Ihrem Server verbinden sollen, auch wenn Sie einer http://-Referenz folgen. Dadurch werden Angriffe wie SSL-Stripping sowie die Umlaufkosten der 301 redirect vermieden, die wir unter HTTP zu HTTPS weiterleiten aktiviert haben.

Aktivieren Sie HTTP Strict Transport Security (HSTS), indem Sie den Header Strict-Transport-Security festlegen. Die HSTS-Seite von OWASP enthält Links zu Anleitungen für verschiedene Serversoftware.

Die meisten Webserver bieten eine ähnliche Möglichkeit, benutzerdefinierte Header hinzuzufügen.

Außerdem muss sichergestellt werden, dass Clients nie Cookies über HTTP senden (z. B. für die Authentifizierung oder Website-Einstellungen). Wenn beispielsweise das Authentifizierungscookie eines Nutzers im Nur-Text-Format offengelegt wird, wird die Sicherheitsgarantie der gesamten Sitzung gelöscht – selbst wenn Sie alles andere richtig gemacht haben.

Ändern Sie daher Ihre Webanwendung so, dass für von ihr festgelegte Cookies immer das Secure-Flag gesetzt wird. Auf dieser OWASP-Seite wird erläutert, wie das Flag „Secure“ in verschiedenen Anwendungs-Frameworks festgelegt wird. Jedes Anwendungs-Framework hat eine Möglichkeit, das Flag festzulegen.

Die meisten Webserver bieten eine einfache Weiterleitungsfunktion. Mit 301 (Moved Permanently) kannst du Suchmaschinen und Browsern mitteilen, dass die HTTPS-Version kanonisch ist, und Nutzer über HTTP zur HTTPS-Version deiner Website weiterleiten.

Suchranking

Google nutzt HTTPS als positiven Indikator für die Suchqualität. Google veröffentlicht auch einen Leitfaden zum Übertragen, Verschieben oder Migrieren einer Website, ohne dabei den Suchrang beizubehalten. Bing veröffentlicht außerdem Richtlinien für Webmaster.

Leistung

Wenn die Inhalts- und Anwendungsebene gut abgestimmt sind (siehe Bücher von Steve Souders), sind die verbleibenden TLS-Leistungsprobleme im Vergleich zu den Gesamtkosten der Anwendung in der Regel gering. Darüber hinaus können Sie diese Kosten reduzieren und amortisieren. (Ausführliche Hinweise zur TLS-Optimierung sowie allgemeine Informationen finden Sie unter High Performance Browser Networking von Ilya Grigorik.) Weitere Informationen finden Sie in Ivan Ristics OpenSSL Cookbook und Bulletsichere SSL And TLS.

In einigen Fällen kann die Leistung durch TLS verbessert werden, hauptsächlich aufgrund der Möglichkeit von HTTP/2. Chris Palmer hat auf dem Chrome Dev Summit 2014 einen Vortrag zur HTTPS- und HTTP/2-Leistung gehalten.

Referrer-Header

Wenn Nutzer Links von Ihrer HTTPS-Website zu anderen HTTP-Websites folgen, senden User-Agents keinen Verweis-Header. Wenn dies ein Problem ist, gibt es mehrere Möglichkeiten, es zu lösen:

  • Die anderen Websites sollten zu HTTPS migrieren. Wenn die eingeladenen Websites den Abschnitt HTTPS auf Ihren Servern aktivieren in diesem Leitfaden ausgeführt haben, können Sie Links auf Ihrer Website von http:// zu https:// ändern oder protokollrelative Links verwenden.
  • Verwenden Sie den neuen Verweisrichtlinien-Standard, um verschiedene Probleme mit Verweis-Headern zu umgehen.

Da Suchmaschinen zu HTTPS migrieren, werden Sie in Zukunft wahrscheinlich mehr Verweis-Header sehen, wenn Sie zu HTTPS migrieren.

Werbeeinnahmen

Betreiber, die ihre Website durch die Auslieferung von Anzeigen monetarisieren, möchten sicherstellen, dass durch die Migration zu HTTPS die Anzeigenimpressionen nicht reduziert werden. Aufgrund von Sicherheitsbedenken im Zusammenhang mit gemischten Inhalten funktioniert ein HTTP-<iframe> jedoch auf einer HTTPS-Seite nicht. Hier gibt es ein schwieriges kollektives Problem: Bis Werbetreibende ihre Website über HTTPS veröffentlichen, können Websitebetreiber nicht zu HTTPS migrieren, ohne dass dabei Werbeeinnahmen verloren gehen. Doch bis Website-Betreiber zu HTTPS migrieren, haben Werbetreibende wenig Motivation, HTTPS zu veröffentlichen.

Werbetreibende sollten ihre Anzeigen wenigstens über HTTPS anbieten. Dazu führen Sie beispielsweise den Abschnitt „HTTPS auf Servern aktivieren“ auf dieser Seite aus. Viele haben es bereits. Sie sollten Werbetreibende, die überhaupt kein HTTPS verwenden, darum bitten, zumindest damit zu beginnen. Sie sollten das Ausführen von IntraSite-URLs relativ aufschieben, bis genügend Werbetreibende ordnungsgemäß interagieren.