Let's Encrypt bietet kostenlose SSL-Zertifikate für die Absicherung von Webservices (Webserver, E-Mail, ...) an. Es lassen sich zwar keine Wildcard-Zertifikate erstellen, aber dafür mehrere einzelne Zertifikate beantragen und zusätzlich Mutidomain-Zertifikate erstellen.

Für das Abrufen der Zertifikate gibt es Tools, die direkt auf dem öffentlich erreichbaren Hostsystem ausgeführt werden und jede einzelne Domain (für die ein Zertifikat beantragt wird) per HTTP oder DNS verifizieren. Und da haben wir in komplexen Infrastrukturen auch schon die größte Hürde:

• Die DNS-Validierung lässt sich nur sinnvoll nutzen, wenn das Tool direkt die DNS-Konfiguration modifizieren kann und fällt damit für alle jene die die eigenen Domains von einem Hoster verwalten lassen flach.

Nicht für jeden Webservice ist es notwendig, ein kostenpflichtiges SSL-Zertifikat von einer anerkannten Registrierungsstelle zu erwerben. So kommen Entwicklungssysteme oder Dienste für eine eingeschränkte nicht-öffentliche Zielgruppe, bei denen es nur auf eine zuverlässige Verschlüsselung, aber nicht auf eine Verifizierung ankommt durchaus mit selbst erstellten Zertifikaten aus.

Self-signed Zertifikat erstellen

Eigene Zertifikate lassen sich mit OpenSSL sowohl unter Linux als auch Windows sehr einfach und rasch mit dem folgenden Befehl erstellen. Die für das Zertifikat notwendigen Daten werden dabei durch das Tool über die Kommandozeile abgefragt. Im unteren Beispiel habe ich ein Zertifikat für einen Entwicklungsrechner erstellt und daher eine Gültigkeit von 10 Jahren (3650 Tage) gesetzt, dieser Wert lässt sich aber beliebig an die eigenen Bedürfnisse anpassen.

Wer seine Website mit HSTS (HTTP Strict Transport Security) absichert, zeigt damit, dass seine Website nur mittels HTTPS erreichbar ist und das impliziert auch, dass immer ein gültiges und von einer öffentlichen CA ausgestelltes und damit vertrauenswürdiges Zertifikat ausgeliefert wird.

HSTS lässt sich auch in Verbindung mit self-signed Zertifikaten nutzen, hat dann aber Konsequenzen beim Wechsel von einem abgelaufenen Zertifikat gegen ein neues selbst-signiertes Zertifikat. Die Browser verweigern, dann nämlich den Aufbau der Verbindung zur Website und ermöglichen es dem Nutzer auch nicht manuelle Ausnahmen zu setzen. Abhilfe schafft in diesem Fall nur das eher unrealistische Szenario, das der Betreiber der Website auf ein vertrauenswürdiges Zertifikat einer CA wechselt oder das Löschen des Browser-Caches am Client, der auf die so abgesicherte Website zugreifen möchte.

Der Apache Webserver bietet mit mod_rewrite ein mächtiges Werkzeug, um URLs zu modifizieren. Die Klassiker sind dabei der Redirect von HTTP auf HTTPS oder auch von einer ganzen Domain auf eine andere (z.B. von example.com auf www.example.com).

Doch nicht immer sollen alle Pfade oder Dateien umgeleitet werden. Einen konkreten Fall bilden die Validierungsdateien für Domains, wie Sie von Let's Encrypt verwendet werden, die immer von der Originaldomain für welche die Zertifikate ausgestellt werden sollen abgefragt werden müssen.

Die folgenden beiden Beispiele zeigen, wie ein Pfad vom Redirect auf HTTPS bzw. auf eine andere Domain ausgenommen werden kann:

Oft dient der Apache Webserver nur als Gateway für weitere im internen Netzwerk liegende Webservices, die aber nach außen hin über Standardports bzw. öffentliche Domains erreichbar gemacht werden sollen. Dazu bedient man sich dem Konzept des Reverse Proxy und dem Apache Modul mod_proxy.

Was aber, wenn zusätzliche Ressourcen von diesen Domains ausgeliefert werden sollen (z.B. Verifizierungsdateien für Google Analytics oder Let's Encrypt, robots.txt, ...), die aber nicht über den eigentlichen Webservice bereitgestellt werden können? Hier kann der Apache Webserver bzw. mod_proxy helfen und einzelne Pfade von der Weiterleitung an das Zielsystem ausnehmen und damit dessen Inhalte selbst bereitstellen. So können dann z.B. global verfügbare Alias-Definitionen oder einzelne virtuelle Verzeichnisse in den Proxy-Hosts verfügbar gemacht werden.

In meinem neuen Gastbeitrag auf www.app-entwicklung.info habe ich einen Blick auf die aktuell am Markt befindlichen mobilen Ökosysteme geworfen und zusammengetragen, welche Alternativen es zu den herrschenden Marktführern Apple, Google und Microsoft eigentlich noch gibt bzw. welche Urgesteine und Emporkömmlinge diesen mittlerweile schon unterlegen sind: Eine aktuelle Übersicht der verfügbaren Betriebssysteme für Mobilgeräte.

Lesen Sie den gesamten Artikel unter www.app-entwicklung.info/2016/12/aktuelle-betriebssysteme/

Apache stellt verschiedene Varianten für die Authentifizierung von Nutzern bereit. Die bekannteste ist wohl AuthType Basic die im Browser eine schnöde Eingabeaufforderung für Benutzername und Passwort erzeugt. Aber der Apache Webserver liefert mit mod_auth_form auch ein Modul mit, mit dem sich ein HTML-Formular für die Anmeldung nutzen und vor allem selbst adaptieren und gestalten lässt.

Module laden

Damit mod_auth_form funktioniert, muss das entsprechende Modul durch Auskommentieren in der httpd.conf geladen werden. Außerdem werden noch weitere Module zum Verarbeiten der Requests und zum Erzeugen und Speichern der Sessions benötigt.

Alfresco hat nicht nur das Namensschema seiner neuen Community Edition Releases verändert, sondern auch etwas am JavaScript der Editoren verändert, bzw. auf die aktuelle Version von TinyMCE umgestellt, weshalb meine Anpassungen und Optimierungen am Editor nicht so einfach vom alten Release übernommen werden können. Daher gibt es eine neue Upgrade-Anleitung inkl. aktualisierten Code-Anpassungen für die Adaptierung des Wiki- und Blog-Editors.

Alfresco neu installieren und konfigurieren

Installieren Sie Alfresco über den Installationsassistenten in ein neues Verzeichnis, um das aktuelle Installation unangetastet zu lassen und die Daten später übernehmen zu können. Damit die parallele Installation einwandfrei klappt, müssen Sie drei Punkte beachten:

Gerade bei einfachen Netzwerkdiensten, wie z.B. einem Medienserver, soll im internen Netzwerk der Zugriff uneingeschränkt möglich sein, aber sobald jemand aus dem Internet darauf zuzugreifen versucht, dies entweder untersagt oder mittels Passwort geschützt sein. Dazu lässt sich die Konfiguration des virtuellen Hosts entsprechend anpassen, um für einzelne IP-Bereiche bereits gemachte Einschränkungen wieder aufzuheben.

Konfiguration ab Apache 2.4

Ab Apache 2.4 wird die RequireAny-Direktive genutzt, um Ausnahmen für die aktivierte Basic-Authentifizierung zu schaffen. In diesem Fall wird der Zugriff gestattet, wenn der Nutzer entweder eine IP aus dem Netzwerk 192.168.0.* nutzt oder einen gültiger Nutzer (Authentifizierung) ist.

Nach dem Update auf Z-Push 2.3 und dem Connector Z-Push Zimbra Backend 65, klappt die Anmeldung nicht mehr und die folgende Fehlermeldung wird in den Logs ausgegeben:

Das Problem liegt an einer geänderten Methode im Quellcode von Z-Push die im ZimbraBackend aufgerufen wird und nun einen weiteren Übergabeparameter erwartet. Eine kleine Anpassung in der Datei zimbra.php des Connectors (zu finden im Z-Push Installationsverzeichnis unter /backend/zimbra/zimbra.php) behebt das Problem.