Skip to content

"Mixed-Content"-Warnungen vermeiden

Wer seine Webseiten auf SSL umstellt, kennt das Problem: eingebundene Bilder, Grafiken, CSS- oder Javascript-Dateien werden hier und dort noch über HTTP aufgerufen, was entweder zu Warnmeldungen im Browser über Mixed Content führt (“Teile dieser Seite sind nicht sicher.”) - oder dazu, dass die “unsicher” eingebundenen Teile nicht nachgeladen werden, mit unschönen Aspekten, wenn Teil des CSS oder des Javascripts plötzlich fehlen.

Das Problem lässt sich natürlich mit einer Volltext-Suche (bspw. nach http:) angehen, aber gerade bei datenbankgestützten Webapplikationen (wie Blogs und CMS) mag der SSL-Check von Jitbit hilfreich sein, der kostenlos bis zu 200 Einzelseiten überprüft.

(Gefunden bei Leitmedium.)

Let's Encrypt und Basic-Auth

Wie man mit Let’s Encrypt ganz einfach an SSL-Zertifikate kommt, hatte ich bereits vor mehr als einem Jahr geschildert - mittlerweile übrigens ganz einfach, denn in Debian stretch ist der Let’s Encrypt-Client (der jetzt certbot heißt) nativ dabei und bringt jetzt auch einen fertigen Cronjob mit.

Aber darum soll es heute gar nicht gehen, sondern vielmehr um die Frage, wie man Let’s Encrypt verwenden kann, wenn die entsprechende Webpräsenz mit einem einfachen Passwortschutz - der basic access authentication oder kurz Basic-Auth - versehen ist. Jeder kennt vermutlich das Popup, das nach Benutzerkennung und Passwort fragt; eine nicht sehr elegante, aber dafür mit praktisch keinem Aufwand verbundene Lösung, die zudem alle Dateien in allen Verzeichnissen der Präsenz schützt, nicht nur Scripts, sondern auch - bspw. - Bilder.

"Let's Encrypt und Basic-Auth" vollständig lesen

Neue Zertifikate von StartCom

Eigentlich nutze ich mittlerweile ja Let’s Encrypt, wenn ich Zertifikate für den Betrieb einer Website benötige. Allerdings gibt es doch noch ein oder zwei Dienste, wo ich seit Ende 2015 auf StartCom setze - und die dortigen, kostenlosen Zertifikate laufen eben nach einem Jahr ab und standen daher jetzt zur Erneuerung an.

"Neue Zertifikate von StartCom" vollständig lesen

letsencrypt jenseits des Webservers

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

"letsencrypt jenseits des Webservers" vollständig lesen

Let's Encrypt - Updates

Im April hatte ich über Let’s Encrypt berichtet, den Dienst, der angetreten ist, das Ausstellen und die Installation von Zertifikaten zu vereinfachen.

Der Betrieb lief seitdem gut und zuverlässig, und nachdem jetzt mehr als 90 Tage vergangen sind, kann ich auch berichten, dass die automatische Erneuerung der Zertifikate vor ihrem Ablauf gleichermaßen zuverlässig funktioniert; bemerkt habe ich sie nur durch die Benachrichtigungs-E-Mail meines Cronjobs. Ich bin also weiterhin sehr zufrieden.

"Let's Encrypt - Updates" vollständig lesen

SSL/TLS für Fortgeschrittene

Hat man dem eigenen Webserver erfolgreich SSL beigebracht und für ein valides Zertifikat gesorgt, bspw. mithilfe von Let’s Encrypt, finden sich in der Konfigurationsdatei (bei Debian: /etc/apache2/mods-available/ssl.conf) noch etliche Schrauben und Rädchen, an denen man drehen kann.

"SSL/TLS für Fortgeschrittene" vollständig lesen

SSL/TLS mit Let's Encrypt

Bereits vergangene Woche berichtete ich von meinen Irrungen und Wirrungen des letzten Jahrzehnts mit SSL/TLS im Web. Erst Ende 2015 hatte ich mich aufgerafft, über StartCom für einige Domains Zertifikate erstellen zu lassen, und parallel die Berichterstattung über Let’s Encrypt verfolgt.

Der Workflow für die Erstellung und Pflege von HTTPS-Zertifikaten kann schnell komplex werden:

  • Am Anfang steht die Erzeugung eines Schlüsselpaares, denn das spätere Zertifikat wird nur derjenige verwenden können, der auch den passenden privaten Schlüssel hat.
  • Dann ist für jedes Zertifikat ein Certificate Signing Request (CSR) zu erstellen; das ist quasi die Roh-Form des späteren Zertifikats mit den notwendigen Informationen, die darin enthalten sein sollen.
  • Dieser CSR muss dann von der Zertifierungsstelle (Certificate Authority, CA) digital signiert werden.
  • Das so entstandene Zertifikat muss gespeichert und in die Webserver-Konfiguration eingebunden werden.
  • Der ganze Ablauf ist nur zielführend, wenn die CA von den verbreiteten Browsern anerkannt ist, den von ihr signierten Zertifikaten also vertraut wird. Dafür wollen die meisten CAs Geld. Zudem müssen sie sich über einen mehr oder weniger aufwendigen Weg zumindest vergewissern, dass derjenige, der ein Zertifikat für einen bestimmten Hostnamen ausgestellt haben möchte, über diesen auch verfügen kann.
  • Zertifikate werden in der Regel nur für einen begrenzten Zeitraum - meistens ein Jahr - ausgestellt. Danach müssen sie (rechtzeitig!) verlängert werden.

Let’s Encrypt ist angetreten, diese Abläufe weitestmöglich zu vereinfachen.

"SSL/TLS mit Let's Encrypt" vollständig lesen

Der eigene Webserver mit SSL/TLS

Datenströme im Netz zu verschlüsseln ist wichtig, aber auch zunehmend Allgemeingut. Telnet würde sicherlich niemand mehr zum Zugriff auf einen entfernten Rechner nutzen; stattdessen nimmt man SSH. Auch bei anderen Protokollen ist die Übertragung von Passworten im Klartext schon lange out: es fing an mit APOP für den Zugriff über POP3 und CRAM-MD5 für SMTP-Auth, und schon etliche Jahre nutze ich nur noch POP3S/IMAPS/SMTPS, also eine komplette Verschlüsselung des gesamten Datenstroms. So hat auch das auf SSH basierende SCP/SFTP schon lange FTP ersetzt, und nachdem sich mittlerweile auch NNTPS und der verschlüsselte Zugriff auf IRC-Server verbreitet haben, bleiben nur noch wenige Protokolle “offen”.

Selbstverständlich sollte auch - zumindest - die Übertragung von Passworten via HTTP gesichert werden, was die Einrichtung von HTTPS erfordert. Je mehr sich webbasierte Dienste und Apps verbreiten, desto wichtiger ist das. Es ist allerdings - leider - nicht ganz so einfach.

"Der eigene Webserver mit SSL/TLS" vollständig lesen
tweetbackcheck