HTTPS auf Ihren Servern aktivieren

Chris Palmer
Chris Palmer
Matt Gaunt

Auf dieser Seite finden Sie eine Anleitung zum Einrichten von HTTPS auf Ihren Servern, einschließlich der folgenden Schritte:

  • Erstellen eines 2048-Bit-RSA-Schlüsselpaars mit öffentlichem und privatem Schlüssel.
  • Generieren einer Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR), in die Ihr öffentlicher Schlüssel eingebettet ist.
  • Sie teilen Ihre CSR an Ihre Zertifizierungsstelle (Certificate Authority, CA), um ein endgültiges Zertifikat oder eine Zertifikatskette zu erhalten.
  • Installieren Sie Ihr endgültiges Zertifikat an einem Ort, der nicht über das Web zugänglich ist, z. B. /etc/ssl (Linux und Unix) oder an einem beliebigen Ort, an dem 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 und öffentliche Schlüssel sowie eine CSR zu generieren.

Generieren Sie ein öffentliches/privates Schlüsselpaar

Generiere zuerst ein 2.048-Bit-RSA-Schlüsselpaar. Kürzere Schlüssel können durch Brute-Force-Angriffe kompromittiert werden, während längere Schlüssel unnötige Ressourcen verbrauchen.

Verwenden Sie den folgenden Befehl, um ein RSA-Schlüsselpaar zu generieren:

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 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 müssen Sie Ihre CSRs auf unterschiedliche Weise einreichen. Dazu kann ein Formular auf der Website oder der Kundenbetreuer per E-Mail gehören. Einige Zertifizierungsstellen oder ihre Reseller automatisieren möglicherweise sogar einen Teil oder den gesamten Prozess, in einigen Fällen auch die Generierung 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.

Sie können Ihren Schlüssel auch mehreren DNS-Namen zuordnen, einschließlich unterschiedlicher Namen (z.B. alle beispiel.de, www.beispiel.de, beispiel.net und www.beispiel.net) oder „Platzhalter“-Namen wie *.example.com.

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 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 sowohl HTTP als auch HTTPS unterstützen. Die meisten Websitebetreiber verwenden jedoch Namensbasiertes virtuelles Hosting, um IP-Adressen zu sparen. Dies ist im Allgemeinen praktischer.

Wenn der HTTPS-Dienst noch nicht auf Ihren Servern verfügbar ist, aktivieren Sie ihn jetzt (ohne Weiterleitung von HTTP zu HTTPS). Weitere Informationen finden Sie unter HTTP zu HTTPS weiterleiten. Konfigurieren Sie Ihren Webserver so, dass die von Ihnen gekauften und installierten Zertifikate verwendet werden. Dafür könnte der 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 regelmäßig Ihre HTTPS-Konfiguration mit dem SSL Server Test von Qualys. Ihre Website sollte die Bewertungen A oder A+ erhalten. Behandeln Sie alles, was eine geringere Bewertung verursacht, als Fehler und bleiben Sie sorgfältig, da ständig neue Angriffe auf Algorithmen und Protokolle entwickelt werden.

Website-interne URLs relativ einrichten

Jetzt, da du deine Website sowohl mit HTTP als auch mit HTTPS ausführst, 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 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 weg.

Das Bereitstellen einer Seite, die HTTP-Ressourcen enthält, mit HTTPS kann Probleme verursachen. Wenn ein Browser auf eine ansonsten sichere Seite stößt, die unsichere Ressourcen verwendet, werden Nutzer gewarnt, dass die Seite nicht vollständig sicher ist. Einige Browser verweigern das Laden oder Ausführen der HTTP-Ressourcen, wodurch die Seite beschädigt wird. Sie können HTTPS-Ressourcen jedoch bedenkenlos in eine HTTP-Seite einfügen. Weitere Informationen zum Beheben dieser Probleme finden Sie unter Gemischte Inhalte beheben.

Wenn Sie HTTP-basierten Links zu anderen Seiten Ihrer Website folgen, kann dies auch zu einem Downgrade von HTTPS auf HTTP führen. Um dieses Problem zu beheben, sollten Sie die Website-internen URLs so relativ wie möglich gestalten, indem Sie sie entweder protokollrelativ (fehlendes Protokoll, das mit //example.com beginnt) oder hostrelativ (beginnend mit dem Pfad, z. B. /jquery.js) festlegen.

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 Links zu anderen Websites.

Aktualisiere deine Links mit einem Skript und nicht manuell, um Fehler zu vermeiden. Wenn sich der Inhalt Ihrer Website in einer Datenbank befindet, testen Sie das Skript an einer Entwicklungskopie der Datenbank. Wenn der Inhalt Ihrer Website nur 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.

Ändern Sie das Protokoll nicht, wenn Sie Verknüpfungen zu anderen Websites erstellen, statt Ressourcen von diesen Websites einzubeziehen. Sie haben keine Kontrolle darüber, wie diese Websites funktionieren.

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 dies zu einem Nachkommen führen, wenn Ihre Website HTTPS für alle Unterressourcen verwendet. Es wird wahrscheinlich eine 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 unterstützt. Dies ist sowieso oft eine gute Idee, da Sie dann das Erscheinungsbild, die Leistung und die Sicherheit Ihrer Website besser kontrollieren können und Sie keinen Dritten vertrauen müssen, um Ihre Website sicher zu halten.

HTTP zu HTTPS weiterleiten

Wenn du Suchmaschinen anweisen möchtest, für den Zugriff auf deine Website HTTPS zu verwenden, platziere mithilfe von <link rel="canonical" href="https://…"/>-Tags im Header jeder Seite einen kanonischen Link.

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 auch dann immer über HTTPS mit Ihrem Server verbinden sollen, 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.

Um HSTS zu aktivieren, lege den Strict-Transport-Security-Header fest. Auf der HSTS-Seite von OWASP findest du Links zu Anleitungen für verschiedene Arten von 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 werden sollte, geht Ihre Sicherheitsgarantie für die gesamte Sitzung verloren, selbst wenn Sie alles richtig gemacht haben.

Um dies zu vermeiden, ändern Sie Ihre Webanwendung so, dass für von ihr gesetzte Cookies immer das Secure-Flag gesetzt wird. Auf dieser OWASP-Seite wird erläutert, wie das Secure-Flag in mehreren 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. Sie können diese Kosten auch reduzieren und amortisieren. Hinweise zur TLS-Optimierung finden Sie unter High Performance Browser Networking von Ilya Grigorik sowie im OpenSSL Cookbook und in BulletProof SSL and TLS von Ivan Ristic.

In einigen Fällen kann die Leistung durch TLS verbessert werden, hauptsächlich dadurch, dass HTTP/2 möglich ist. Weitere Informationen finden Sie im Vortrag von Chris Palmer zur Leistung von HTTPS und HTTP/2 auf dem Chrome Dev Summit 2014.

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 von einer eingeladenen Website der Abschnitt HTTPS auf Ihren Servern aktivieren in diesem Leitfaden ausgeführt wurde, 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.

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 nicht auf einer HTTPS-Seite. Bis Werbetreibende ihre Website über HTTPS veröffentlichen, können Websitebetreiber nicht zu HTTPS migrieren, ohne dass dadurch Werbeeinnahmen beeinträchtigt werden. Allerdings haben sie kaum Motivation, HTTPS zu veröffentlichen, bis sie auf HTTPS umgestellt werden.

Sie können mit Werbetreibenden beginnen, die Werbedienste über HTTPS anbieten, und Werbetreibende, die überhaupt kein HTTPS nutzen, bitten, dies zumindest in Betracht zu ziehen. Möglicherweise müssen Sie das Ausführen von IntraSite-URLs relativ verschieben, bis genügend Werbetreibende ordnungsgemäß interagieren.