RapidWeaver, HTTPS und Mixed Content.

HTTPS ist ein sicheres Übertragungsprotokoll für Daten, bei dem die Daten verschlüsselt werden. Wenn du eine mit HTTPS übertragene Webseite aufrufst kann niemand die Verbindung mitlesen. Wichtig ist das v.a. bei Webseiten, die persönliche Daten übertragen, z.B. Kontaktformulare und Shops. 

Google bewertet deshalb HTTPS-Webseiten suchmaschinentechnisch besser, diese Seiten ranken in den ...

Wenn du eine Seite betrachtest, die über HTTPS bereitgestellt wird, ist die Verbindung mit TLS verschlüsselt und deshalb geschützt gegen Sniffer und Man-in-the-Middle-Angriffe.

Google bewertet deshalb HTTPS-Webseiten suchmaschinentechnisch besser, diese Seiten ranken in den Suchergebnisseiten besser.

Datenschutzrechtlich ist HTTPS-Verschlüsselung für Kontaktformulare und Shops mittlerweile vorgeschrieben, es wurden sogar schon Bussgelder für Webseitenbetreiber verhängt, die sich einen feuchten Kehricht und die Sicherheit ihrer Seiten gekümmert haben. Einige Browser (Chrome, Firefox) zeigen beim Aufruf unverschlüsselter Seiten einen Warnhinweis. Alles Grund genug, sich um einen Wechsel von HTTP zu HTTPS zu kümmern.


Du brauchst ein SSL-Zertifkat.

Bei deinem Hoster musst du deiner Domain ein SSL-Zertifikat zuweisen. Bei den meisten Hostern sollte das kein Problem darstellen, i.d.R sind auch ein - zwei Zertifikate kostenlos, manchmal sogar alle.

Anschließend sollte deine Seite über "https://" aufrufbar sein. Ein Problem ist aber die bestehen bleibende Aufrufbarkeit der Domain über "http://". Du musst deinen Server also zwingen, Aufrufe von "http//" auf "https://" umzuleiten.

Teilweise kannst du das bei deinem Hoster in der Domainverwaltung konfigurieren ("HTTPS erzwingen"). Geht das nicht, schreibst du eine ReWrite_Rule in die .htaccess (Apache-Server):

RewriteEngine On RewriteCond %{HTTPS} !=onRewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] 

Läuft die betreffende Website auf einem Nginx Webserver, musst du in der VHost-Konfiguration des Nginx-Webservers dies hinzugefügen:

server { listen 80; . server_name example.com; return 301 https://example.com$request_uri; } 

Bitte teste anschließend, wie sich deine Webseite verhält und ob die Umleitung von HTTP nach HTTPS funktioniert.


Probleme mit gemischten Inhalten.

Wenn deine Seite verschlüsselt übertragen wird, bist du soweit erst einmal auf der sicheren Seite. Ein Problem gibt es aber, wenn deine mit HTTPS verschlüsselte Seite Inhalte enthält, die über reguläres HTTP, d.h. unverschlüsselt und im Klartext abgerufen werden, denn dann ist die Verbindung nur teilweise verschlüsselt: Der unverschlüsselte Inhalt ist weiterhin zugänglich für Sniffer und kann durch Man-in-the-Middle-Angriffe verändert werden, weshalb die Verbindung insgesamt nicht mehr geschützt ist.

Das passiert beispielsweise, wenn du Content in deine Webseite einbindest, der von unsicheren HTTP-Seiten abgerufen wird. Oft ist das beispielsweise bei Warehousing von Assets, die dann über eine unsichere HTTP-URL aufgerufen werden, der Fall.

Das passiert aber auch, wenn externe Skripte, die z.B. auf einem CDN (Content Delivery Network) gehostet werden, mit einem http://-Link eingebunden werden. Selbst wenn der externe Server die Weiterleitung auf HTTPS erzwingt, ist der Aufruf erst einmal unverschlüsselt. Das gleiche bei der Einbindung von Webfonts, die von einem externen Server geladen werden und mit einem http://-Link eingebunden wurden.

Eine Website, die dieses Verhalten aufweist, wird als Mixed Content-Seite bezeichnet. Es gibt einige Browser (Chrome und Firefox), die dann eine Warnung ausgeben. Schreckhafte und ängstliche Seitenbesucher wird solch eine Warnung natürlich sofort in die Flucht schlagen.


Zwei Arten von Mixed Content.

Mixed Content ist nicht gleich Mixed Content:

  • Passiver Mixed Content: Webinhalte, die andere Teile einer Website nicht ändern können, sondern einfach nur ausgeliefert werden. Dazu gehören Bilder, Videos, Audio-Dateien und Object-SubRessourcen in eine Website eingebunden sind
  • Aktiver Mixed Content: Webinhalte, die als ausführbare Dateien funktioneller Teil einer Website sind. Diese Webinhalte können Teile einer Website und/oder deren Verhalten nachhaltig verändern. Dazu gehören z.B Skripte (z.B. JavaScript), iFrames oder auch CSS-Dateien in denen mit URLs gearbeitet wird


(Fast) keine Probleme mit RapidWeaver.

Mit RapidWeaver sollte es eigentlich keine großen Probleme beim Wechsel von HTTP zu HTTPS geben. Die Links, über die die Seite intern verknüpft ist und mit der Inhalte eingebunden werden, sind in der Regel relative Verlinkungen. Wenn du in RapidWeaver in den General Settings die Basis-URL deines Projekts auf "https://" änderst, sollte das reichen, solange die Links in deinem Projekt relative Links sind. Ein Problem entsteht durch absolute Links, da diese auf eine vollständige URL weisen, die du alle auf "https://" umschreiben musst. Allerdings wirst du im Normalfall "relative Verlinkung" eingestellt haben.

Ein Problem könnte es mit extern eingebundenem Inhalt geben: Warehousing, externe Skripte und Webfonts stehen hier im Vordergrund. Wenn du solchen über unverschlüsselte Verbindungen eingebundenen Content in deiner Seite eingebunden hast, enthält die Seite Mixed Content und einige Browser werden nun Warnungen ausgeben.

Du wirst auf die Suche nach unverschlüsselt eingebundenem Content gehen müssen. Dabei kann dir ein kleines Tool helfen: HTTPSChecker. Damit kannst du deine komplette Site auf Mixed Content hin überprüfen - in der kostenlosen Version ist die Überprüfung allerdings auf 500 Einzelseiten bzw. Dokumente beschränkt und diese Grenze ist schnell erreicht.

Eine andere Hilfe ist whynotpadlock, ein kostenloses Online-Tool, das allerdings immer nur ein einzelnes HTML-Dokument überprüft.

Ein drittes Tool ist JitBit SSL Check, allerdings ist die Zahl der gescannten Seiten auf 200 begrenzt.

Gefundenen Mixed Content kannst du mit diesen Tools aufspüren und anschließend im Projekt manuell korrigieren.


Probleme mit alten Themes.

Probleme könnte es mit älteren Themes geben, die aus einer Zeit stammen, in der HTTPS noch keine große Rolle gespielt hat. Hier sind oft externe Webfonts oder Skripte über eine HTTP-Verlinkung eingebunden.

Damit mit solchen Themes erstellte Projekte keine Probleme machen, musst du deine Themes bearbeiten. Du öffnest die index.html des Themes mit einem Texteditor und suchst nach HTTP-Verlinkungen. Du überprüfst, ob die Linkziele auch über HTTPS erreichbar sind und schreibst die Links auf "https://" um.

Beispiel: Im gar nicht mal so alten Theme "Paramount" von Michael David Design sind Google-Fonts über unverschlüsselte Verbindungen verlinkt:

<link href='http://fonts.googleapis.com/css? etc...


Hier musst du "http//" mit "https//" ersetzen.

Etwas problematischer wird das bei CSS-, PHP- und Javascript-Dokumenten. Soweit hier unverschlüsselte Links zu finden sind, braucht es schon etwas Fachwissen um zu verschlüsselten Verbindungen zu kommen. Im Zweifel wird dir wenig anderes übrig bleiben, entweder den Theme-Entwickler um ein Update seines Themes zu bitten oder aber zu einem anderen Theme zu wechseln. Meist ist das aber gar nicht nötig.