In diesem Artikel behandelte Schritte
- Erstellen Sie ein 2048-Bit-RSA-Schlüsselpaar mit öffentlichem und privatem Schlüssel.
- Generieren Sie einen Zertifizierungsantrag (Certificate Signing Request, CSR), der Ihren öffentlichen Schlüssel einbettet.
- Teilen Sie Ihre CSR mit Ihrer Zertifizierungsstelle, um ein endgültiges Zertifikat oder eine Zertifikatskette zu erhalten.
- Installieren Sie das endgültige Zertifikat an einem Ort, der nicht über das Web zugänglich ist, z. B. unter
/etc/ssl(Linux und Unix) oder an einem Ort, an dem IIS es benötigt (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.
Paar aus öffentlichem und privatem Schlüssel generieren
Beginnen wir mit der Generierung eines 2.048-Bit-RSA-Schlüsselpaars. Ein kleinerer Schlüssel wie 1.024 Bit ist nicht ausreichend resistent gegen Brute-Force-Angriffe. Ein größerer Schlüssel, z. B. 4.096 Bit, ist zu viel. Mit der Zeit nehmen die Schlüsselgrößen zu, da die Computerverarbeitung immer günstiger wird. 2.048 ist derzeit der ideale Punkt.
Der Befehl zum Generieren des RSA-Schlüsselpaars lautet:
openssl genrsa -out www.example.com.key 2048
Dies ergibt die folgende Ausgabe:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
Anfrage zur Zertifikatsignierung generieren
In diesem Schritt betten Sie Ihren öffentlichen Schlüssel und Informationen über Ihre Organisation und Ihre Website in eine Anfrage zur Zertifikatsignierung oder CSR ein. Der Befehl openssl fragt Sie interaktiv nach den erforderlichen Metadaten ab.
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 []:
Prüfen Sie mit dem folgenden Befehl, ob die CSR gültig ist:
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
Verschiedene Zertifizierungsstellen (Certificate Authorities, CAs) benötigen unterschiedliche Methoden, um ihnen Ihre CSRs zu senden. Dazu kann beispielsweise ein Formular auf der Website oder das Senden der CSR per E-Mail verwendet werden. Einige Zertifizierungsstellen (oder ihre Reseller) automatisieren 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 der Anleitung, um Ihr endgültiges Zertifikat oder Ihre Zertifikatskette zu erhalten.
Die verschiedenen Zertifizierungsstellen berechnen unterschiedliche Beträge für den Dienst zum Einlösen des öffentlichen Schlüssels.
Sie können den 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 Platzhalternamen wie *.beispiel.de.
Beispielsweise bietet eine Zertifizierungsstelle derzeit folgende Preise an:
- Standard: 16 $/Jahr, gültig für example.com und www.example.com.
- Platzhalter: 150 $/Jahr, gültig für example.com und *.example.com.
Zu diesen Preisen sind Platzhalterzertifikate kostengünstig, wenn Sie mehr als neun 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 Front-End-Server an einem nicht über das Web zugänglichen Ort wie /etc/ssl (Linux und Unix) oder an einem Ort, an dem IIS (Windows) sie erfordert.
HTTPS auf Ihren Servern aktivieren
Die Aktivierung 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 entscheidende operative Entscheidung treffen. Wählen Sie eine der folgenden Optionen aus:
- Weisen Sie jedem Hostnamen, über den Ihr Webserver Inhalte bereitstellt, eine eindeutige IP-Adresse zu.
- Verwenden Sie Namensbasiertes 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 Websitebetreiber verwenden jedoch Namensbasiertes virtuelles Hosting, um IP-Adressen zu sparen und im Allgemeinen praktischer zu sein. Das Problem mit Internet Explorer unter Windows XP und Android vor Version 2.3 besteht darin, dass er Server Name Indication (SNI) nicht versteht, was für das name-basierte virtuelle Hosting mit HTTPS entscheidend ist.
Irgendwann – hoffentlich bald – werden Clients, die SNI nicht unterstützen, durch moderne Software ersetzt. Überwachen Sie den User-Agent-String in Ihren Anfragelogs, um zu erfahren, wann genügend Nutzer zu moderner Software migriert sind. Sie können den Grenzwert selbst bestimmen – möglicherweise unter 5 % oder unter 1%.
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 von Ihnen erworbenen und installierten Zertifikate verwendet werden. Vielleicht finden Sie den praktischen Konfigurationsgenerator von Mozilla hilfreich.
Wenn Sie viele Hostnamen oder Subdomains haben, muss jeder das richtige Zertifikat verwenden.
Überprüfen Sie jetzt und während der gesamten Lebensdauer Ihrer Website Ihre HTTPS-Konfiguration mit dem praktischen SSL-Servertest von Qualys. Ihre Website sollte eine A oder A+ erhalten. Behandeln Sie alles, was eine niedrigere Bewertung verursacht, als Fehler. (Das heutige A ist das B von morgen, da sich Angriffe auf Algorithmen und Protokolle immer verbessern.)
Website-interne URLs relativieren
Da Sie Ihre Website nun sowohl über HTTP als auch über HTTPS bereitstellen, muss unabhängig vom Protokoll alles so reibungslos wie möglich funktionieren. Ein wichtiger Faktor ist die Verwendung von relativen URLs für Intrasite-Links.
Achte darauf, dass die protokollunabhängigen URLs innerhalb der Website und externe URLs unabhängig vom Protokoll sind. Verwende also relative Pfade oder gib das Protokoll wie //example.com/something.js weg.
Wenn Sie eine Seite mit HTTP-Ressourcen, also gemischten Inhalten, über HTTPS bereitstellen, tritt ein Problem auf. Browser warnen Nutzer, dass die volle Leistung von HTTPS verloren gegangen ist. Tatsächlich werden bei aktiven gemischten Inhalten (Script, Plug-ins, CSS, iFrames) die Browser häufig einfach die Inhalte überhaupt nicht geladen oder ausgeführt, was zu einer fehlerhaften Seite führt. Und nicht vergessen: Es ist völlig in Ordnung, HTTPS-Ressourcen in eine HTTP-Seite einzufügen.
Wenn Sie auf andere Seiten Ihrer Website verlinken, kann es passieren, dass ein Downgrade von HTTPS auf HTTP für Nutzer durchgeführt wird.
Diese Probleme treten auf, wenn Ihre Seiten voll qualifizierte interne URLs enthalten, die das http://-Schema verwenden.
<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>Vermeidet die Verwendung von voll qualifizierten URLs innerhalb der Website.
Mit anderen Worten: Gestalten Sie Website-interne URLs so relativ wie möglich: entweder protokollrelative (fehlendes Protokoll, das mit //example.com beginnt) oder Hostrelativ (nur mit dem Pfad beginnend, z. B. /jquery.js).
<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>Verwende relative URLs innerhalb der Website.
<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.
<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>Verwende für intersite-URLs HTTPS-URLs (falls möglich).
Dies geschieht mit einem Skript, nicht von Hand. Wenn sich die Inhalte Ihrer Website in einer Datenbank befinden, testen Sie Ihr Skript mit einer Entwicklungskopie Ihrer Datenbank. Wenn der Inhalt Ihrer Website aus einfachen Dateien besteht, testen Sie Ihr Skript mit einer Entwicklungskopie der Dateien. Übertragen Sie die Änderungen wie gewohnt erst in die Produktion, nachdem sie 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 du Links zu anderen Websites einfügst, solltest du das Protokoll nicht ändern, da du keine Kontrolle über die Funktionsweise dieser Websites hast.
Für eine reibungslosere Migration großer Websites empfehlen wir protokollrelative URLs. Wenn Sie nicht sicher sind, ob Sie HTTPS noch nicht vollständig bereitstellen können, kann es zu einer Nach hinten ausgelöst werden, wenn auf Ihrer Website HTTPS für alle Unterressourcen verwendet wird. Vermutlich ist HTTPS für dich schon eine Zeit lang neu und ungewöhnlich und die HTTP-Website muss weiterhin wie gewohnt funktionieren. Im Laufe der Zeit schließen Sie die Migration ab und sorgen dafür, dass HTTPS verwendet wird (siehe die nächsten beiden Abschnitte).
Wenn Ihre Website von Skripts, Bildern oder anderen Ressourcen abhängt, 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 HTTPS nicht bereitstellt, bitten Sie ihn darum. Die meisten tun das bereits, einschließlich jquery.com.
- Stellen Sie die Ressourcen von einem Server bereit, den Sie kontrollieren und der sowohl HTTP als auch HTTPS unterstützt. Dies ist sowieso oft eine gute Idee, da Sie dann das Aussehen, die Leistung und die Sicherheit Ihrer Website besser kontrollieren können. Außerdem müssen Sie keinem Drittanbieter vertrauen, was immer gut ist.
HTTP zu HTTPS weiterleiten
Du musst im Header deiner Seite einen kanonischen Link einfügen, um Suchmaschinen mitzuteilen, dass HTTPS die beste Methode 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 deiner Website gelangen.
Strict Transport Security und sichere Cookies aktivieren
Jetzt können Sie sich auf die Verwendung von HTTPS einstellen.
- Verwende HTTP Strict Transport Security (HSTS), um die Kosten einer 301-Weiterleitung zu vermeiden.
- Setzen Sie bei Cookies immer das Sicherheits-Flag.
Verwenden Sie zuerst Strict Transport Security, um Clients anzuweisen, eine Verbindung zu Ihrem Server immer über HTTPS herzustellen, auch wenn sie einer http://-Referenz folgen. Dadurch werden Angriffe wie SSL-Striping verhindert. Außerdem werden die Umlaufkosten für die 301 redirect vermieden, die unter HTTP zu HTTPS weiterleiten aktiviert wurden.
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 zum Hinzufügen benutzerdefinierter Header.
Außerdem ist es wichtig, dass Clients niemals Cookies (z. B. zur Authentifizierung oder für Website-Einstellungen) über HTTP senden. Wenn beispielsweise das Authentifizierungscookie eines Nutzers im Nur-Text-Format offengelegt wird, würde die Sicherheitsgarantie der gesamten Sitzung verloren gehen – selbst wenn Sie alles andere richtig gemacht haben.
Daher sollten Sie Ihre Webanwendung so einstellen, dass für von ihr gesetzte Cookies immer das Secure-Flag gesetzt wird. Auf dieser OWASP-Seite wird erläutert, wie Sie das Secure-Flag in mehreren Anwendungs-Frameworks setzen. Jedes Anwendungs-Framework hat eine Möglichkeit, das Flag festzulegen.
Die meisten Webserver bieten eine einfache Weiterleitungsfunktion. Verwende 301 (Moved Permanently), um Suchmaschinen und Browsern anzuzeigen, dass die HTTPS-Version kanonisch ist, und leite deine Nutzer über HTTP zur HTTPS-Version deiner Website weiter.
Suchranking
Google verwendet HTTPS als positiven Suchqualitätsindikator. Google veröffentlicht auch einen Leitfaden zum Übertragen, Verschieben oder Migrieren einer Website unter Beibehaltung des Suchrangs. Bing veröffentlicht auch Richtlinien für Webmaster.
Leistung
Wenn die Inhalts- und Anwendungsebenen gut abgestimmt sind (siehe die Bücher von Steve Souders für große Empfehlungen), sind die verbleibenden TLS-Leistungsprobleme im Verhältnis zu den Gesamtkosten der Anwendung in der Regel gering. Darüber hinaus können Sie diese Kosten reduzieren und amortisieren. Weitere Informationen zur TLS-Optimierung sowie allgemein finden Sie unter High Performance Browser Networking von Ilya Grigorik. Weitere Informationen finden Sie im OpenSSL-Cookbook und im Bulletproof SSL And TLS von Ivan Ristic.
In einigen Fällen kann die Leistung durch TLS verbessert werden, hauptsächlich aufgrund der Möglichkeit von HTTP/2. Chris Palmer sprach auf dem Chrome Dev Summit 2014 über die Leistung von HTTPS und HTTP/2.
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 eingeladene Websites den Abschnitt HTTPS auf Ihren Servern aktivieren in diesem Leitfaden erfolgreich ausführen, können Sie Links auf Ihrer Website von
http://zuhttps://ändern oder protokollrelative Links verwenden. - Verwenden Sie den neuen Verweisrichtlinienstandard, um eine Vielzahl von Problemen mit Verweisheadern zu umgehen.
Da Suchmaschinen zu HTTPS migrieren, werden Sie in Zukunft wahrscheinlich mehr Verweis-Header sehen, wenn Sie zu HTTPS migrieren.
Werbeeinnahmen
Websitebetreiber, die ihre Website durch das Ausliefern von Anzeigen monetarisieren, möchten sicherstellen, dass durch die Migration zu HTTPS nicht weniger Anzeigenimpressionen erzielt werden. Aufgrund von Sicherheitsproblemen mit gemischten Inhalten funktioniert ein HTTP-<iframe> jedoch auf einer HTTPS-Seite nicht. Hier besteht ein komplexes kollektives Problem: Bis Werbetreibende ihre Website über HTTPS veröffentlichen, können Websitebetreiber nicht zu HTTPS migrieren, ohne Werbeeinnahmen zu verlieren. Aber bis die Websitebetreiber zu HTTPS migrieren, haben Werbetreibende wenig Motivation, HTTPS zu veröffentlichen.
Werbetreibende sollten ihren Werbedienst zumindest über HTTPS anbieten. Lesen Sie dazu beispielsweise den Abschnitt "HTTPS auf Ihren Servern aktivieren" auf dieser Seite. Viele haben es bereits. Sie sollten Werbetreibende, die kein HTTPS verwenden, zumindest den Einstieg bitten. Sie sollten das Abschließen von IntraSite-URLs relativ aufschieben, bis genügend Werbetreibende ordnungsgemäß miteinander interagieren.