HTTPS mit einem offiziellen SSL-Zertifikat zur Suchmaschinenoptimierung

(Last Updated On: 1. August 2018)

Eigentlich gibt es nicht mehr viele Talks über das Thema HTTPS. Das Thema ist schon seit langem nicht mehr „heiß“ und wurde bereits in den frühen 2000ern durchgekaut. Der Kontext ist simpel: Wenn Ihre Webanwendung mit den Anwendern sensible Informationen austauscht, sollten diese verschlüsselt sein. Sonst können andere mitlesen, die unterwegs den Netzverkehr zwischen Webserver und Anwender-Browser abfangen. Zwar gibt es auch heute noch sicherheitstechnische Feinheiten, auf die man achten sollte (ich berichtete beispielsweise über eine Liste unsicherer Cipher Suiten), jedoch ist der Prozess zur Implementierung von HTTPS heutzutage als Routine anzusehen.

Mit Hilfe von LetsEncrypt ist jetzt auch sehr einfach geworden, eine HTTPS-Verschlüsselung mit einem selbstsignierten Zertifikat in seinen Webserver zu integrieren. Sehr viele Webseiten sind daher auf HTTPS umgestiegen. Häufig wird jedoch weiterhin HTTP-Verkehr angeboten, da private Blogs beispielsweise keine sensiblen Informationen mit ihren Besuchern austauschen.

Wenn HTTPS also so ein alter Schuh ist – warum reden jetzt auf einmal wieder so viele Blogs und Online-Magazine über HTTPS? Warum blogge ich über das Thema? Nun, weil nun auch Google erkannt hat, dass HTTPS in einem Webauftritt im Jahr 2018 zum Standard gehören sollte und deshalb in ihrer organischen Trefferergebnisliste solche Webangebote bevorzugt, die mit HTTPS abgesichert sind und sich mit einem gültigen, von einer offiziellen CA unterzeichneten, Zertifikat ausweisen.

Das Schlüsselwort hierbei ist das Zertifikat. Sich ein selbstsigniertes Zertifikat auszustellen ist nicht nur einfach, sondern auch kostenlos. Das Problem: Außenstehende können selbst unterzeichneten Zertifikaten nicht vertrauen, weil dies kein eindeutiger Nachweis für die Identität des Webservers ist. Man möchte ja wissen, ob der Webserver, den man gerade ansurft, auf wirklich dem Betreiber gehört, welchen man hinter einer Domain erwartet. Sonst könnte jemand, der beispielsweise den Google DNS Server gekapert hat, auf seinen Webserver umleiten und sich gegenüber anderen mit einem selbst signierten Zertifikat als „google.com“ ausgeben.

Um hier mehr Vertrauen in die Sache zu bringen, gibt es offizielle Certificate Authorities (CAs), welche die Identität eines Betreibers anhand beispielsweise einer Ausweiskopie feststellen und diesem dann ein Zertifikat ausstellen. Dieses Zertifikat kann er im Anschluss auf seinem Webserver hochladen und sich dann gegenüber seinen Besuchern ausweisen. Das Zertifikat sagt dann: „Ja, dies ist das offizielle Zertifikat welches dem Inhaber von dafrk-blog.com gehört, das ist Beweis dafür, dass dieser Webserver auch von diesem Betreiber betrieben wird.“

Vertrauenslevel bei SSL-Zertifikaten

Die Art und Weise, wie die Certificate Authority die Identität des Betreibers feststellt, bestimmt ihre Vertrauenswürdigkeit. Einige CAs verlangen lediglich, dass der Betreiber einen DNS-Eintrag setzt, wodurch für die CA ersichtlich ist, dass der Eintrag von einem Administrator gesetzt wurde, der Zugriff auf die DNS-Konfiguration der jeweiligen Domain hat. Es könnte jedoch auch sein, dass ein Hacker, welcher sich unbefugt Zugang zu diesem DNS-Server verschafft hat, die Anfrage an die CA stellt und in diesem Zuge den DNS-Eintrag setzt.

Daher ist es beispielsweise sicherer, wenn die CA  zusätzlich eine Personalausweiskopie vom Betreiber verlangt. Diese erhöhte Sicherheit kostet natürlich. Da die CA nun auch eine Auskunft über die Personalausweisdaten des Antragstellers einholen muss, sind Zertifikate von CAs, welche die Identität des Betreibers überprüfen, teurer. Dafür gelten Sie auch allgemein als sicherer.

Die Crux an der Sache: Die zusätzliche Vertrauenswürdigkeit wird häufig von den Besuchern einer Website nicht anerkannt, weil sie entweder den Unterschied nicht kennen, oder weil es ihnen egal ist. Deshalb bleibt die einzige Frage, wenn man nicht gerade ein seriöser großer Online-Shop wie Amazon oder eine Bank ist: Wie bewertet denn Google die Vertrauenswürdigkeit eines Zertifikats. Mit welchem Zertifikat bekomme ich den größten „Bang for the buck“? Denn häufig will man ja einfach nur Google wegen der Suchergebnisse zufrieden stellen, und nicht die Besucherschaft, die mit dem Begriff eines TLS-Zertifikates meist auch gar nichts anfangen kann.

Single Domain, Multi Domain und Wildcard Zertifikate

Unabhängig davon, welches Vertrauenslevel ein SSL-Zertifikat erfüllt, unterscheidet man, ob dieses Zertifikat für nur eine einzige Top Level Domain (z. B. dafrk-blog.com, ohne irgendwas davor), für mehrere Domains (für dafrk-blog.com, www.dafrk-blog.com und mail.dafrk-blog.com) oder für alle Domains (dafrk-blog.com und jedes x-beliebige Präfix davor) gültig ist.

Es kann mitunter günstiger sein, bei mehreren Subdomains nur ein Multi Domain Zertifikat zu kaufen statt einem Wildcard-Zertifikat. Betreibe ich beispielsweise nur dafrk-blog.com, www.dafrk-blog.com und mail.dafrk-blog.com, ist es vermutlich günstiger, ein Multi Domain Zertifikat für diese drei Subdomains zu kaufen, als ein großes Wildcard-Zertifikat.

Wenn Sie ein SSL-Zertifikat für lediglich eine einzige große Domain brauchen, müssen Sie sich diesen Gedanken gar nicht erst machen. Sie sollten ohnehin möglichst wenige Subdomains verwenden und stattdessen all Ihren Content möglichst unter einer einzigen großen Domain anbieten. Denn das macht es für Sie leichter, die einzelnen Inhalte für Suchmaschinen zu optimieren.

Verschiedene Typen von SSL/TLS Zertifikaten

Man unterscheidet grundsätzlich folgende Typen von SSL-Zertifikaten

  • Extended Validation SSL-Zertifikate (EV). Hier prüft die CA das Recht des Antragstellers, einen spezifischen Domain Namen zu verwenden, und führt zusätzliche eine Überprüfung der dahinter stehenden Organisation durch. Die Schritte, die hierbei von der CA durchzuführen sind, wurden im Jahr 2007 vom CA/Browser Forum ratifiziert. sie umfassen die Überprüfen der Existenz der gesetzlichen, materiellen und betrieblichen Existenz der „Einheit“ (natürliche oder juristische Person). Bei dieser Art von Zertifikat wird also geprüft, ob eine juristische Person wirklich eingetragen ist (Betriebsverzeichnisse, Handelsregister, Steuernummer o. Ä.), die Existenz der hinterlegten Geschäftsadresse wird geprüft, die Ausweiskopie des Inhabers wird angefordert, es wird das Setzen eines DNS-Eintrages verlangt usw. EV-Zertifikate sind am schwersten zu kriegen und damit auch am teuersten. Nicht alle CAs dürfen auch EV-Zertifikate ausstellen, hierfür müssen diese nämlich selbst gewisse Kriterien erfüllen. EV-Zertifikate sind für ein gutes Google-Listing nicht nötig und sollten für ein seriöses Auftreten gegenüber anspruchsvollen Kunden gewählt werden.
  • Organization Validated SSL-Zertifikate (OV). Selbes wie EV, nur dass hier die Überprüfung der Organisation nicht so tief gehend ist. Die Kriterien zur Erlangung eines OV-Zertifikates an die Organisation sind schlicht und ergreifend geringer. Daher sind OV-Zeritfikate grundsätzlich etwas günstiger. In der Praxis haben OV-Zertifikate eine relativ geringe Bedeutung, da sich Organisationen entweder aufgrund des Preises für ein DV-Zertifikat entscheiden, oder aufgrund der Reputation für ein EV-Zertifikat
  • Domain Validated SSL-Zertifikate (DV). Bei dieser Zertifikatsform erfolgt eine Validierung des Zertifikatseigentümers lediglich über einen DNS-Eintrag. Das heißt der Inhaber nimmt eine DNS-Konfiguration in seiner Domain vor und weist dadurch nach, dass der Admin-Zugriffe auf die DNS-Verwaltung hat. Diese Zertifikate sind durch diesen automatisierbaren Prozess sehr günstig.

Grundsätzlich lässt sich im Hinblick auf die Suchmaschinenoptimierung folgendes sagen: Es kümmert Google nicht, welche Art von Zertifikat Ihr Webserver vorweist, solange es von einer anerkannten CA ausgestellt ist. Ein Domain-validated Zertifikat ist also mehr als genug. Da Let’sEncrypt eine automatisierte Domain-Validierung vornimmt, sind die kostenlosen Let’s Encrypt Zertifikate absolut ausreichend für eine Suchmaschinenoptimierung. Es gibt also aus Sicht der Suchmaschinenoptimierung keinen Grund dazu, Geld für ein SSL-Zertifikat auszugeben. Das sollten Sie einzig und allein aus Imagegründen machen. Solange Ihre Besucherschaft in dieser Richtung keine Ansprüche stellt, generieren Sie sich einfach ein domain-validiertes Zertifikat über Let’s Encrypt für lau.

Zertifikate sind eine Grundvoraussetzung für HTTP2

Da wir schon beim Zusammenhang zwischen Zertifikaten und ihrer Rolle in Verbindung mit Google Suchergebnissen sind: Wie Sie vielleicht wissen bewertet Google ein Listing auch anhand seiner Ladezeit. Das bedeutet, wenn die Ladezeit Ihrer Seite sehr gering ist, bevorzugt Sie Google gegenüber einem Suchergebnis mit ähnlicher Relevanz, da Sie Ihren Content schneller und damit auch komfortabler an die Benutzer herantragen.

HTTP2 ist ein gutes Mittel dafür, die Ladezeiten Ihres Webauftritts zu reduzieren. Denn im Gegensatz zu HTTP 1.0 bzw. HTTP 1.1 muss der Webserver unter HTTP 1.1 nicht mehr warten, bis eine Datei (etwa eine .html, .jpeg oder .css-Datei) heruntergeladen wurde, bevor die nächste begonnen werden kann. HTTP 2.X ist komplett parallelisierbar. Es können also sämtliche HTML-Ressourcen einer Webseite parallel heruntergeladen werden. Dies beschleunigt die Ladezeit Ihrer Webseiten signifikant. Die meisten heutigen Webbrowser unterstützten den Standard schon. Wenn sie also Ihren Webserver die Auslieferung von Webseiten über HTTP2 ermöglichen, haben Sie einen massiven Wettbewerbsvorteil gegenüber Ihren Konkurrenten.

Damit Sie jedoch HTTP2 betreiben können, ist ein SSL-Zertifikat absolute Grundvoraussetzung, denn HTTP2 hat die Verschlüsselung integriert und braucht aus diesem Grund auch einen Identitätsnachweis in Form eines Zertifikats. Wenn Sie ein Zertifikat implementieren, werden Sie von Google also mitunter gleich zweimal belohnt: Einmal weil Sie HTTPS grundsätzlich anbieten, und einmal weil Ihre Ladezeiten schneller werden.

Beanwortungszeiten von Zertifikatsanbietern sind irrelevant  – dank OCSP

In den früheren Jahren hatte man teurere Zertifikatsanbieter noch gewählt, weil man sich hier Gedanken über die Beantwortungszeit einer Zertifikatsüberprüfung an eine CA  gemacht hatte. Aus dem oberen Abschnitt haben wir ja erörtert, dass die Ladegeschwindigkeit einer Website ein wichtiger Ranking-Faktor in der Google-Suchergebnisliste ist. Sobald Verschlüsselung und damit auch ein SSL-Zertifikat im Spiel ist, gehört zu dieser Ladezeit auch die Beantwortung einer simplen Frage.

Und zwar stellt der Webbrowser des Besuchers an die Certificate Authority (CA), welche das Zertifikat unterschrieben hat, eine Frage. Nämlich, ob das Zertifikat auch wirklich von dieser CA ausgestellt und unterschrieben wurde. Sonst könnte das ja jeder behaupten. Diese Anfrage geschieht über ein Netzwerkprotokoll namens Online Certificate Status Protocol (OCSP) Das Problem: Die CA allein bestimmt, wie schnell sie auf diese Anfrage antwortet. Grundsätzlich ist es zwar auch heute noch so, dass teurere CAs meist eine bessere Infrastruktur haben und daher solche Zertifikatsanfragen schneller beantworten. Jedoch kann man dieses Problem heutzutage in den Hintergrund blenden.

Denn heutzutage gibt es eine Technologie namens OCSP Stapling. Bei dieser Technologie bezieht der Webserver regelmäßig vom Zertifikatsanbieter (also von der CA) eine Antwort über das Zertifikat, mit dem er sich gegenüber seinen Benutzern ausweist. Diese Antwort ist von der Certificate Authority signiert und ist nur eine begrenzte Zeit gültig, kann also nicht gefälscht werden. Der Webserver speichert die Antwort von der CA nun zwischen.

Wenn nun der Benutzer den Webserver ansurft, schickt er eine Anfrage nach der Gültigkeit des Zertifikates. Unterstützt der Webbrowser des Besuchers OCSP Stapling, schickt er diese Anfrage jedoch nicht an die CA selbst, sondern an den Webserver, den er ohnehin gerade ansurft. Hat der Webserver eine OCSP-Antwort von der CA zwischengespeichert, sendet er diese nun an den Webbrowser des Besuchers. Die Certificate Authority beantwortet also die OCSP-Antwort des Besuchers nur noch indirekt. Dadurch, dass die OCSP-Antwort, die der Webserver zwischengespeichert hat, von der CA signiert ist, kann diese Antwort nicht gefälscht werden.

Damit OCSP Stapling genutzt werden kann, muss einmal der Webbrowser des Besuchers dies unterstützen, und einmal der Webserver. Folgende Webserver unterstützen das Verfahren.

  • Microsoft IIS ab Version 8.0
  • Apache ab 2.3.3
  • nginx ab 1.3.7

Sie sehen also – aktuelle Webserver können von diesem Feature Gebrauch machen. Sie müssen danach nur noch sicher gehen, dass das Feature entsprechend aktiviert ist. Beim Apache Webserver definieren Sie dazu die folgenden Direktiven.

SSLStaplingCache shmcb:/tmp/stapling_cache(102400)
SSLUseStapling on
SSLStaplingReturnResponderErrors off

Hierfür muss im Apache Webserver das Modul socache_shmcb aktivert sein und der Webserver muss firewall-seitig eine Verbindung zum OCSP-Responder aufbauen können.

Wenn Sie sich unsicher sind, ob Ihr Webserver OCSP Stapling unterstützt, oder jetzt gerade die Konfigurationseinstellungen vorgenommen haben und diese validieren wollen, können Sie den Online-Test von SSLLabs ausführen. Sobald OCSP bei Ihnen konfiguriert ist, können Sie also ruhig zu einem günstigeren SSL-Zertifikat von einem Anbieter mit höherer Response Time greifen.

Was Sie jedoch vor der Auswahl eines SSL-Zertifikats beachten sollten

Jetzt, da wir elaboriert haben, dass die Beantwortungszeit auf eine OCSP-Anfrage keine Rolle spielt, unterscheiden sich die einzelnen Zertifikatsanbieter doch in zwei entscheidenden Punkten. Google hat mit seinem Browser Chrome den Anfang gemacht und markiert alle Zertifikate, die lediglich mit einem SHA-1 Algorithmus gehasht sind, als unsicher.  Eigentlich sollten alle neu ausgestellten Zertifikate entsprechend mit SHA-2 gehasht werden, aber überprüfen Sie diesen Parameter, bevor Sie ein Zertifikat bei einer CA erwerben.

Als zweites ist es wichtig zu verstehen, dass Google Chrome (und nur dieser Browser) allgerisch gegen Zertifikate reagiert, die von der Symantec-CA oder von verwandten Autoritäten (RapidSSL, GeoTrust und Thawte) reagiert. Obwohl die Zertifikate von einer offiziellen CA unterzeichnet und mit ShA-2 gehasht sind, markiert der Chrome Browser diese dennoch in der Browserzeile als unsicher. Grund dafür sind diverse Vorfälle mit von Symantec ausgestellten CAs in der Vergangenheit. Auf das Suchmaschinen-Ranking hat dies scheinbar zwar keinen großartigen Einfluss, jedoch auf das Image gegenüber Webseiten-Besuchern, welche die Webseite über den Chrome-Browser besuchen. Eventuell sollten Sie also darüber nachdenken, stattdessen einen anderen Anbieter zu wählen.

Einen suchmaschinenfreundlichen HTTPS-Redirect einstellen

War Ihr Webauftritt in der Vergangenheit über HTTP erreichbar, haben Sie von verschiedenen Websiten bestimmt Backlinks bekommen, die noch das HTTP-Protokoll nutzen. Daher ist es grundsätzlich unklug, HTTP bei Ihnen gänzlich zu deaktivieren und nur noch HTTPS auf Ihrem Webserver zu zu lassen. Damit Suchmaschinen weiterhin die alten Backlinks auf das HTTP-Protokoll berücksichtigen können, aber nun die neuen HTTPS-URLs Ihrer Website in ihren Index aufnehmen, sollten Sie einen SEO-freundlichen 301 Redirect einrichten.

Einige Web-Administrationsoberflächen wie cPanel oder Plesk bieten hierfür bereits sehr einfache GUI-Bedienelemente, die die Einrichtiung eines solchen Redirects recht einfach machen. Unter Onyx Plesk begeben Sie sich hierfür beispielsweise in die Hosting Settings.

HTTPS HTTP2 Suchmaschinenoptimierung SEO SSL Zertifikat

Und richten dann im Folgefenster den Redirect ein.

Permanent SEO Safe 301 Redirect Onyx Plesk

Falls Sie kein Admin Panel nutzen, können Sie ihn auch manuell über beispielsweise eine .htaccess Datei setzen

RewriteEngine on
RewriteCond %(HTTPS) !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Die Umstellung auf HTTPS bietet Stolpersteine für SEO

Um sicherzugehen, dass sich eine HTTPS-Umstellung nicht negativ für die eigene Suchmaschinenplatzierung auswirkt, sollte man auf die Stolpersteine in diesem Zusammenhang achten. Das erste was Sie machen sollten, nachdem Sie Ihre WordPress-Instanz permanent auf HTTPS umgestellt haben, ist unter Einstellungen -> Allgemein die Basis-URLs auf die https-Version umzustellen.

Wordpress HTTPS Mixed Content beheben und fixen

WordPress HTTPS Mixed Content beheben und fixen

Die häufigsten Probleme im Zusammenhang mit einer HTTPS-Umstellung sind

  • Crawlen Sie vor der Umstellung mit einem Webcrawler wie On-Crawl mit einer Crawltiefe von 1  all Ihre URLs. Crawlen Sie nach der Umstellung erneut und stellen Sie sicher, dass durch den Redirect keine URLs verloren gegangen sind. Ihre Redirects können Sie beispielsweise
  • Stellen Sie die bisherigen Links in Ihrem Content vo HTTP auf HTTPS um, beispielsweise über Datenbankmittel.
  • Prüfen Sie, ob Ihre Redirects sauber funktionieren und vermeiden Sie unnötige Redirects, da diese Ihre Ladezeiten erhöhne. Mit einem Browser Addon wie beispielsweise Ayima Redirect Path für Google Chrome können Sie den Redirect-Path für Ihre URLs prüfen.
    HTTPS Umstellung WordPress Redirects prüfen
  • Ressourcen wie beispielsweise JavaScript-Dateien (.js), CSS-Dateien (.css), Bilder sowie Ihre XML-Sitemap (.xml) sollten nun über HTTPS hinterlegt sein. Ansonsten bekommen Sie im Browser eine Warnung über „Insecure Content“. Das wollen Sie vermeiden. Sie können mit dem Webtool „Why no Padlock?“ prüfen, wo Ihre Seite noch insecure content hat.

Um beispielsweise all Ihre Bilder in Ihren WordPress-Beiträgen von HTTP- auf HTTPS-Links umzustellen, können Sie folgendes SQL Statement (beispielsweise über PHPMyAdmin) absetzen.  Machen Sie vorher jedoch auf jeden Fall ein Backup Ihrer Datenbank. Vor dem Absetzen des SQL Statements ist wichtig, dass der Name der Tabelle wp_posts abweichen kann, wenn Sie bei der WordPress-Installation ein anderes Table Prefix gewählt haben, und dass Sie dafrk-blog.com durch Ihre Domain ersetzen. Vergessen Sie auch nicht, die Version ohne www. zu nehmen.

UPDATE wp_posts SET `post_content` = REPLACE (`post_content`, 'src="http://dafrk-blog.com', 'src="https://dafrk-blog.com');
UPDATE wp_posts SET `post_content` = REPLACE (`post_content`, 'src="http://www.dafrk-blog.com', 'src="https://www.dafrk-blog.com');
Bei einer Multisite Installation müssen die Query sogar für die einzelnen Seiten-IDs wiederholen
UPDATE wp_<seiten_id>_posts SET `post_content` = REPLACE (`post_content`, 'src="http://yourdomain.com', 'src="https://yourdomain.com');
Danach müssen Sie auch noch die GUIDs der einzelnen Bilder, die als Anhang konfiguriert sind, bearbeiten. Das geht mit dieser Query
UPDATE wp_posts SET `guid` = REPLACE (`guid`, 'http://dafrk-blog.com', 'https://dafrk-blog.com') WHERE post_type = 'attachment';
Bei einer Multisite-Installation ergo wieder:
UPDATE wp_<id>_posts SET `guid` = REPLACE (`guid`, 'http://yourdomain.com', 'https://<ourdomain.com') WHERE post_type = 'attachment';
Für URLs in Tabellen einzelner Plugins oder Themes kann man sich beispielsweise der „Suchen und Ersetzen“ Funktion von PHPMyAdmin bedienen
Mit dem Suchen und Ersetzen Feature von PHPMyAdmin stellen wir von HTTP auf HTTPS um. Wir verwenden protokoll-relative Pfade
Um alle Dateien zu finden, die noch http://meinedomain.com-Links enthalten, loggen Sie sich auf Kommandozeilenebene ein, begeben Sie sich in das Root-Verzeichnis der WordPress-Installation, und führen Sie aus
grep -lrnw . -e 'http://dafrk-blog.com'

Auch hier ersetzen Sie die Domain wieder durch Ihre eigene und wiederholen das Kommando mit der www.-Version.

Sie können mit folgender Linux-Kommandozeile alle diese Links in eine protokoll-relative URL umwandeln.

find httpdocs/ -type f -exec sed -i -e 's,http://,//,g' {} \;

dabei ist httpdocs relativ vom aktuellen Verzeichnis das htdocs- bzw. Document Root Verzechnis der jeweiligen Webpräsenz.  Die Zeile schreibt alle http://-Links in //-Links um. Dies führt dazu, dass immer das aktuelle Protokoll der Hauptseite genutzt wird. Wenn Sie einen HTTPS-Redirect erzwingen, ist das wiederum immer HTTPS.

  • Externe Tools, wie beispielsweise Social Media APIs, Heatmaps, Analysetools, E-Mail-Marketing Werkzeuge usw. müssen ggf. umkonfiguriert werden, da sie noch auf die HTTP-URL zeigen.
  • Fügen Sie die HTTPS-Version Ihrer Website zur Google SearchConsole hinzu (sowohl mit als auch ohne www.) und Aktualisieren Sie Ihre Disavow-Datei für diese Version. Bezüglich des Google Disavow Tools habe ich bereits in der Vergangenheit einen Blogbeitrag geschrieben.

Wenn alle Stricke reißen, helfen WordPress-Plugins wie beispielsweise der SSL Insecure Content Fixer weiter. Dieser schreibt HTTP-Links on the fly in HTTPS-Links um und sollte damit Fehlermeldungen wie beispielsweise „Diese Seite versucht, Skripts aus nicht authentifizierten Quellen zu laden.“, verscheuchen.

Aus Sicherheitsgründen: Aktivieren Sie HSTS

Immer dann, wenn ein Besucher ihre Website über das HTTP-Protokoll aufruft und er im Anschluss über einen 301 Redirect auf die HTTPs-Variante umgeleitet wird, birgt dies ein Sicherheitsrisiko. Denn einige Daten, wie beispielsweise die Session-ID der einer Webanmeldung, werden bereits vor diesem 301 Redirect über das HTTP-Protokoll übertragen. Diese Informationen könnten also von einem Man in the Middle abgegriffen werden. Um dies zu verhindern, sollten Sie die Kommunikation von Daten ausschließlich über HTTPS zulassen. Dies konfigurieren Sie, indem Sie den sogenannten HSTS-Header setzen.

Im Admin-Panel von Onyx Plesk gibt es diese Option derzeit nicht in der GUI (hierfür gibt es jedoch derzeit eine Support-Anfrage). Sie müssen stattdessen, wie bei der manuellen Konfiguration eines Webservers auch, den Header über die Webserver-Konfiguration setzen lassen. Dies können Sie jedoch wiederum in der grafischen Oberfläche über  Domains > <Ihre Domain> > Apache & nginx Settings durchführen.

Tragen Sie nun die folgenden Direktiven ein.

für einen nginx Webserver:

add_header Strict-Transport-Security "max-age=31536000" always;

für einen Apache Webserver:

Header always set Strict-Transport-Security "max-age=31536000"

Unter WordPress erzwingen Sie außerdem durch folgenden Eintrag in der wp-config.php noch, dass SSL beim Zugriff auf das Admin-Bakcend verwendet werden muss.

define(‚FORCE_SSL_ADMIN‘, true);

Herzlichen Glückwunsch – Ihr Webauftritt ist nun nicht nur suchmaschinenoptimiert, sondern auch noch ein Stückchen sicherer geworden.

Source :

DFN-PKI blog

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.