Select Page

NETWAYS Blog

SSL leicht gemacht – forcierte Weiterleitung von HTTP auf HTTPS einrichten

This entry is part 3 of 5 in the series SSL leicht gemacht


In den vorherigen Teilen der Serie wurde bereits die Erstellung und Einbindung der Zertifikate beschrieben. Eines Tages wünscht sich der Admin jedoch die sichere Verbindung aller Seitenbesucher, ohne dass diese manuell ein https voranstellen müssen. Gerade bei einer Migration einer bestehenden Seite wird der
Parallelbetrieb erst nach eingehenden Tests eingestellt und das SSL jeweils forciert, um Seitenbesucher nicht mit ungültigen Zertifikaten oder Mixed Content zu verunsichern.
Die eigentliche Umsetzung ist dann relativ einfach und wird in unserem Beispiel direkt in der Vhost-Definition des Apache vorgenommen. Übrigens, die verfügbaren Vhosts sind zu finden unter: /etc/apache2/sites-available. Hier wird nun der HTTP-Vhost (Port 80) um den unten aufgezeigten Block mit den Rewrites erweitert.

<VirtualHost *:80>
  ServerAdmin webmaster@netways.de
  ServerName www.netways.de
  DocumentRoot /var/www/html/netways.de/
  <Directory /var/www/html/netways.de/>
   Options FollowSymLinks
   AllowOverride All
  </Directory>
  ErrorLog /var/log/apache2/error.log
  LogLevel warn
  CustomLog /var/log/apache2/access.log combined
  RewriteEngine on
  RewriteCond %{SERVER_NAME} =www.netways.de [OR]
  RewriteCond %{SERVER_NAME} =netways.de
  RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
 </VirtualHost>

Damit das Ganze nun auch funktioniert, muss natürlich der SSL-Vhost unter Port 443 erreichbar sein. Wie dieser initial erstellt wird, ist im Artikel SSL-Zertifikat einbinden beschrieben.
Übrigens: wer Let’s Encrypt verwendet, wird im Wizard gleich gefragt, ob SSL forciert werden soll. Der Wizard übernimmt dann die oben gezeigten Schritte. Wie man Let’s Encrypt einsetzt, haben wir natürlich auch schon einmal beschrieben. Damit später keine Seitenbesucher verloren gehen, sollte der HTTP-Vhost, der auf Port 80 läuft, nicht abgeschaltet werden. Die Verbindung ist mit dieser Maßnahme sicher und alle Besucher werden auf https umgeleitet.
Wer damit gar nichts zu tun haben will, und trotzdem stets auf der sicheren Seite sein will, der kann natürlich seine Seite auch bei NETWAYS im Managed Hosting betreuen lassen. Hier kümmern wir uns darum.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

SSL leicht gemacht – Zusammengehörigkeit von Zertifikaten überprüfen

This entry is part 5 of 5 in the series SSL leicht gemacht

Kürzlich hatten wir den Fall, dass uns ein Zertifikat auf einen alten CSR ausgestellt wurde und wir beim Einbinden in den Webserver Fehler erhielten.
Im Apache äußerte sich das ganze mit der Logausgabe:

[error] Unable to configure RSA server private key
[error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

Dahingehend wurde bei der Einrichtung und Erneuerung der Zertifikate bei uns der Workflow angepasst. Jetzt werden zusätzlich vor dem Einlesen der Config noch die Prüfsummen der einzelnen Bestandteile verglichen, um solche Fehler zu vermeiden.
Mit den nachfolgenden Kommandos lassen sich die jeweiligen Prüfsummen ausgeben. Diese müssen jeweils zu allen anderen übereinstimmen.

openssl rsa -noout -modulus -in /etc/apache2/ssl/netways.de/netways.de.key | md5sum
d0ed27eb1ecf771abc1e789c96e9b640
openssl req -noout -modulus -in /etc/apache2/ssl/netways.de/netways.de.csr | md5sum
d0ed27eb1ecf771abc1e789c96e9b640
openssl x509 -noout -modulus -in /etc/apache2/ssl/netways.de/certificate.crt | md5sum
d0ed27eb1ecf771abc1e789c96e9b640

Dann klappts auch mit dem Zertifikat und man kann sich sicher sein, alle zusammengehörigen Dateien zu haben.
Hinweis: Im Internet gibt es SSL Validation Checker wie Sand am mehr, allerdings rate ich auch an dieser Stelle dringend davon ab, SSL Keyfiles aus Produktionsumgebungen aus der Hand zu geben und in ein Online-Formular einzufügen. Diese Online-Checker greifen übrigens auch nur auf dieses einfache Verfahren zurück.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

SSL leicht gemacht – Zertifikat einbinden (Apache2)

This entry is part 1 of 5 in the series SSL leicht gemacht

In meinem letzten Blogpost habe ich über die Erstellung eines Keyfiles und eines CSR geschrieben. Im zweiten Teil meiner Serie SSL leicht gemacht zeige ich den nächsten Schritt und beschreibe die Einrichtung des Zertifikates mittels der Webserversoftware Apache.
Bestandsaufnahme:
nun sollten folgende Dateien vorhanden sein

  • selbst erstellt
    • CSR (in unserem Beispiel netways.de.csr)
    • Privatekey (netways.de.key)
  • von Zertifizierungsstelle erstellt und übermittelt
    • cert.cabundle
    • certificate.crt

Diese Zertifikatsdateien können jetzt auf dem Webserver eingerichtet werden.
Als nächstes werden die Zertifikatsdateien im korrekten Verzeichnis abgelegt. Hierzu eignet sich zum Beispiel /etc/apache2/ssl/netways.de/. Hier sollte die Zusammengehörigkeit der einzelnen Dateien noch einmal überprüft werden. Der CSR wird übrigens nicht mehr benötigt und kann gelöscht werden.
Apache kann im Moment noch nichts mit den Zertifikatsdateien anfangen und noch lernen “SSL zu sprechen”. Dazu wird ein SSL-VHost eingerichtet. Als Basis hierfür kann der abzusichernde VHost vorerst kopiert werden.

cp /etc/apache2/sites-available/001-netways.de.conf /etc/apache2/sites-available/001-netways.de-ssl.conf

Diese neue SSL-Config wird nun angepasst, damit der Apache nun weiß, was er zu tun hat.
Innerhalb der nun betreffenden VHost-Definition werden nun noch ein paar Paramater für SSL angegeben

SSLEngine on
 SSLCertificateKeyFile /etc/apache2/ssl/netways.de/netways.de.key
 SSLCertificateFile /etc/apache2/ssl/netways.de/certificate.crt
 SSLCertificateChainFile /etc/apache2/ssl/netways.de/cert.cabundle

Übrigens in der Einleitung der VHost-Definition (i. d. R. ganz oben in der neuen Datei) sollte der angegebene Port 80 auf 443 geändert werden.

<VirtualHost 123.456.789.012:80> auf <VirtualHost 123.456.789.012:443>

Abschließend wird der Apache noch um ein paar Funktionalitäten erweitert (SSL und der neue VHost wird aktiviert):

a2enmod ssl
a2ensite 001-netways.de-ssl.conf
service apache2 restart

Der VHost ist nun zusätzlich mit SSL abgesichert und in unserem Beispiel via https://netways.de und http://netways.de erreichbar. Ob alles geklappt hat, sieht man nun am erfolgreichen Verbindungsaufbau via HTTPS oder kann es zum Beispiel bei SSL Labs ausführlich prüfen lassen.
Die Namensgebung der Zertifikate unterscheidet sich von Zertifizierungsstelle zu Zertifizierungsstelle und kann auch mal mit .pem bezeichnet sein usw. Dies kann “ignoriert” werden und beliebig selbst in der Config auf die neuen Endungen angepasst werden. Auch eine Umbenennung der Dateien auf das eigene Schema ist ein möglicher Lösungsansatz.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

SSL leicht gemacht – CSR und Keyfile erstellen und Zertifikat ordern

This entry is part 2 of 5 in the series SSL leicht gemacht

Oftmals kommt trotz der breiten Verfügbarkeit von Letsencrypt der Wunsch nach kostenpflichtigen Zertifikaten auf. Die Gründe sind vielfältig: längere Gültigkeit, Wildcard-, Multidomain- oder Extended-Validation (Grüne-Leiste) Zertifikate – all das bietet Letsencrypt leider nicht und deshalb ist der Bedarf nach solchen Zertifikaten noch immer vorhanden. In den nächsten Wochen werden wir immer wieder Blogposts zum Thema SSL erstellen, alle zu finden in unserer Serie “SSL leicht gemacht”
Zu aller Anfang wird ein CSR (Certificate Signing Request) und ein Keyfile (privater Schlüssel) benötigt. Aus Sicherheitsgründen empfehlen wir prinzipiell die Erstellung gleich auf dem Zielsystem des Zertifikates vorzunehmen, so müssen die Daten nicht umgezogen werden und bleiben nicht “zufällig” irgendwo liegen.
Los geht’s mit dem Kommando

openssl req -new -nodes -keyout netways.de.key -out netways.de.csr -newkey rsa:4096

Dadurch wird im aktuellen Verzeichnis ein Privatekey mit einer Schlüssellänge von 4096 Bit (default 2048) angelegt. Der folgende Wizard sammelt nun noch die Daten für das CSR ein.
Hier wird nach dem Land, dem Staat, der Stadt, der Firma, der Abteilung, der zu sichernden Domain und der Kontaktmailadresse gefragt. Eingaben können auch leergelassen werden und mit der Eingabetaste übersprungen werden (ACHTUNG: Defaultwerte (sofern vorhanden) aus den eckigen Klammern werden übernommen).
Zur Kontrolle kann das CSR noch mit dem Kommando

openssl req -in netways.de.csr -noout -text

überprüft werden. Übrigens gibt es bei Umlauten (wie so oft) Probleme. Wir vermeiden diese gern durch die Verwendung englischer Städtenamen wie im aktuellen Beispiel zu sehen.
Abschließend kontrollieren wir das Keyfile noch (zumindest, ob es so in der Art aussieht).

Fertig, nun geht man zur Bestellung des Zertifikates über. Hierzu kann man auf jeden beliebigen Zertifikatshändler zurückgreifen. Wegen anhaltender “Unstimmigkeiten” bei Google und Symantec empfehle ich persönlich (bei der Neubestellung) auf Produkte von Comodo zurückzugreifen. Die Comodo-Zertifikate sind preislich im Mittelfeld und die Akzeptanz der Zertifikate ist hoch. Für die Bestellung wird nur der CSR benötigt. Das Keyfile sollte keinesfalls an irgendjemanden weitergegeben werden und auf dem Server verbleiben.
Bei der Bestellung werden nochmal alle möglichen Daten, gewünschte Laufzeit usw. abgefragt. Unter anderem auch die Mailadresse. Die Auswahlmöglichkeiten dieser ist oftmals beschränkt. Die ausgewählte Mailadresse muss zwingend verfügbar sein, um die Validierung via Mail abzuschließen und ein Zertifikat zu erhalten. Sofern alles geklappt hat, bekommt man später in der Regel per Mail das Zertifikat und ggf. das CA-Bundle zugeschickt.
Wie das alles nun zusammen eingerichtet wird, schreibe ich im Artikel Zertifikat einbinden (Apache2).
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Support-Chat für die eigene Website – mit Rocket.Chat

Rocket.Chat bietet neben der umfangreichen Vernetzung bestehender Teams auch ein ganz besonderes Feature, den Supportchat. Dieser eignet sich für Websitenbetreiber, um direkt und ohne Wartezeit mit dem Besucher kommunizieren zu können. In diesem Artikel gehe ich einmal auf die Einrichtung und Einbindung eines solchen Supportchats auf der eigenen Website ein.
Installation
Zu Beginn muss Rocket.Chat installiert und auf einer Public-Domain erreichbar gemacht werden. Diese Domain muss auch für die weitere Verwendung bei der Einrichtung von Rocket.Chat angegeben werden.
Einrichtung
Die Einrichtung ist mit wenigen Klicks erledigt. Wichtig: In jedem Fall sollte die manuelle Freischaltung des Userkontos (der Support-Kollegen) erfolgen, anderenfalls kann sich jeder einfach registrieren und den Support-Chat als Dritter auch unterstützen. Zu finden ist diese Option unter Administration->Accounts->Registration “

Einbindung
Nun geht es eigentlich schon zum letzten Schritt, der Einbindung auf die Website. In der Administrationsoberfläche des Livechats ist nun der Quellcode zum Einbetten des eigenen Iframes vorbereitet. Dieses Script muss bei auf jeder Webiste auftauchen, auf der der Supportchat erscheinen soll. Das Ganze sieht dann in etwa so aus.

<!-- Start of Rocket.Chat Livechat Script -->
<script type="text/javascript">
(function(w, d, s, u) {
 w.RocketChat = function(c) { w.RocketChat._.push(c) }; w.RocketChat._ = []; w.RocketChat.url = u;
 var h = d.getElementsByTagName(s)[0], j = d.createElement(s);
 j.async = true; j.src = 'https://222-rocketchat-63af3-web.nws.netways.de/packages/rocketchat_livechat/assets/rocket-livechat.js';
 h.parentNode.insertBefore(j, h);
})(window, document, 'script', 'https://222-rocketchat-63af3-web.nws.netways.de/livechat');
</script>
<!-- End of Rocket.Chat Livechat Script -->

Am Ende kann noch etwas am Erscheinungsbild geschraubt werden, damit sich der Chat sauber in die eigene Seite einfügt. Fertig! Um weitere Agents als Supportkollegen in den Chat aufzunehmen, müssen diese noch in der Admin-Bereich des Livechats als “Livechat-Agents” hinzugefügt werden.
Wie werden die Anfragen verteilt?
Falls mehrere Kollegen im Livechat zur Verfügung stehen, so werden die Anfragen Round Robin an diese verteilt. Wenn kein Kollege online ist, fordert der Livechat etwas Geduld vom Besucher und schickt eine E-Mail an den Websitenbetreiber mit den eingegebenen Kontaktdaten.
Aus Kundensicht zu testen ist unser toller Livechat in seiner vollen Pracht auf unserer NWS-Website (wir freuen uns über jede Anfrage). Dort kann selbiger auch direkt als eigene Instanz für 30 Tage völlig kostenfrei und unverbindlich getestet werden – ohne Einschränkungen!
Unsere Kunden profitieren stets von den aktuellsten Software-Versionen, höchster Verfügbarkeit, freundlichem Support und fairen Preisen. Bei allen unserer NWS-Instanzen erhalten Sie natürlich vollen Administrationszugriff und teilen sich die Applikation nicht mit anderen Kunden. Alle Applikationen stehen binnen Sekunden ready-to-use zur Verfügung.
Übrigens, für WordPress und andere Applikationen gibt es bereits fertige Rocket.Chat Livechat Plugins.
Interesse? erfahren Sie mehr über unsere Rocket.Chat-Pakete