blog.bartlweb - a technologist's external brain

Thema: Server

cURL kann URLs mit HTTPS nicht abrufen

Ich habe versucht mit meiner PHP-Installation und cURL eine Website mit HTTPS abzurufen und dabei die folgende Fehlermeldung erhalten:

Uncaught exception 'GuzzleHttp\Exception\RequestException' with message 'cURL error 60: SSL certificate problem: unable to get local issuer certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)'

Das Problem liegt darin, dass cURL die aktuellen Root-Zertifikate der offiziellen Zertifizierungsstellen nicht kennt. Das lässt sich ganz einfach durch Aktualisieren bzw. Bereitstellen dieser Liste beheben.

Laden Sie dazu unter curl.haxx.se/ca/cacert.pem die aktuelle Liste herunter und legen Sie diese im Installationsverzeichnis Ihrer PHP-Installation ab. Danach editieren Sie die PHP-Konfigurationsdatei php.ini und geben für den Parameter curl.cainfo den Pfad zur Zertifikatsdatei an.

curl.cainfo = "C:/Program Files (x86)/PHP/cacert.pem"

Upgrade-Horror bei VMware Workstation

Updates sind wichtig: Es gibt Fehlerbehebungen, gestopfte Sicherheitslücken und eventuell sogar neue Funktion. Bei VMware Workstation ist das Update aber jedes Mal aufs Neue ein kleiner Kampf.

Während beim Update zwar alle Einstellungen erhalten bleiben, muss zumindest einer der vmrun nutzen möchte, sich jedes Mal erneut um das Modifizieren des VIX Wrappers kümmern (siehe vmrun von VMWare Workstation 12 kann sich nicht mit dem Host verbinden) und auch dann ist die korrekte Funktionsweise nicht immer gewährleistet (siehe vmrun funktioniert nach Update auf VMware Workstation 12.5.2 nicht mehr zuverlässig).

Response Policy Zones zum Überschreiben von DNS-Einträgen am BIND Nameserver nutzen

Es gibt unterschiedliche Szenarien, bei denen es notwendig werden kann im lokalen Netzwerk DNS-Einträge für einzelne Domains (egal ob eigene oder nicht durch einen selbst verwaltete) zu manipulieren. Sei es um den Zugriff auf externe Ressourcen aus dem internen Netzwerk zu unterbinden oder eine Split-DNS-Konfiguration für eine eigene von einem externen Domainserver verwaltet Domain zu realisieren.

Seit Version 9.8 unterstützt der BIND Nameserver das Konzept von Response Policy Zones mit der genau solche Anforderungen sehr einfach, ohne Domains am eigenen Nameserver zu verwalten und damit doppelt abzubilden, realisieren lassen.

vmrun funktioniert nach Update auf VMware Workstation 12.5.2 nicht mehr zuverlässig

Nach der Aktualisierung meiner Installation von VMware Workstation auf die neuste verfügbare Version 12.5.2, habe ich wieder einmal getestet ob vmrun wie eigentlich zu erwarten funktioniert.

C:\Program Files (x86)\VMware\VMware VIX>vmrun -T ws-shared -h https://localhost
:8333/sdk list
Host user: admin
Host password:
Unable to connect to host.
Error: Insufficient permissions in the host operating system

Leider ist das noch immer nicht der Fall und daher muss auch weiterhin das Skrpting-Interface VMware VIX wie im Artikel vmrun von VMWare Workstation 12 kann sich nicht mit dem Host verbinden beschrieben modifiziert werden.

Allerdings erhalte ich auch danach immer noch sporadische aber durchaus reproduzierbar Fehlermeldungen, die auf Fehler in der Kommunikation hindeuten:

SAN Error bei der Anfrage von Let’s Encrypt-Zertifikaten mit dem Skript getssl

Für die Anfrage und Verwaltung meiner Let's Encrypt-Zertifikate nutze ich das Skript getssl (github.com/srvrco/getssl). Dabei habe ich die Anforderung Zertifikate für mehrere Domains mit SAN (Subject Alternative Name) zu beantragen. Die Domains habe ich dazu in die Konfigurationsdatei getssl.cfg der Basisdomain eingetragen. Beim Request der Zertifikate erhalte ich allerdings folgende Fehlermeldung:

"Error Loading request extension section SAN
140325313369760:error:2206D06D:X509 V3 routines:X509V3_parse_list:invalid null value:v3_utl.c:299:
140325313369760:error:22097069:X509 V3 routines:DO_EXT_NCONF:invalid extension string:v3_conf.c:139:name=subjectAltName,section=DNS:webserver-bartlwebnet-public.letsencrypt.bartlweb.net,DNS:,DNS:webssh.bartlweb.net,DNS:wordclock.bartlweb.net
140325313369760:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:v3_conf.c:93:name=subjectAltName, value=DNS:webserver-bartlwebnet-public.letsencrypt.bartlweb.net,DNS:,DNS:webssh.bartlweb.net,DNS:wordclock.bartlweb.net
"
getssl: Sign failed: "detail": "Error parsing certificate request. Extensions in the CSR marked critical can cause this error: https://github.com/letsencrypt/boulder/issue/565

Dieser Fehler tritt auf wenn im CSR (Certificate Signing Request) leere Domains als SAN eingetragen sind. Für das Skript getssl heißt das, zu berücksichtigen, dass in der Konfigurationsdatei getssl.cfg die Liste der Domains für den Parameter SANS= nicht mit einem führenden , beginnt, da ansonsten eine leere Domain in den Antrag mit aufgenommen wird.

Alternative zu StartSSL Wildcard- und Multidomain-Zertifikaten mit Let’s Encrypt

StartSSL stellt sehr kostengünstige SSL-Zertifikate bereit, da nur für die Validierung der eigenen Identität einmal ein verhältnismäßig kleiner Kostenbeitrag von $60 anfällt und dann ein Jahr lang beliebig viele Zertifikate und vor allem auch Wildcard- und Multidomain-Zertifikate bezogen werden können.

Mit der Sperre von WoSign in allen großen Browsern und Betriebssystemen Ende 2017, werden auch die Zertifikate von Startcom nicht mehr als gültig erachtet. Alle bisher ausgestellten Zertifikate werden weiterhin bis zu Ende deren Gültigkeitsdauer, neu ausgestellte Zertifikate aber gar nicht mehr, akzeptiert.

Eine wirkliche Alternative in dieser Preisklasse, vor allem für Wildcard- und Multidomain-Zertifikate, existiert aktuell nicht, denn ein Multidomainzertifikat mit 3 Domains kommt auf ca. €800 pro Jahr.

Let’s Encrypt in Enterprise-Setups ohne DNS-Validierungsmöglichkeit per HTTP-Validierung einrichten

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.

Self-signed Zertifikate für lokale Webservices mit OpenSSL selbst erstellen

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.

Pfade oder Dateien von Redirects mit mod_rewrite in Apache ausnehmen

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:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/.*$ [NC]
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/.*$ [NC]
RewriteRule ^(.*)$ https://www.example.com/ [R=301,L]

Eigene Ressourcen in Website die mit mod_proxy von Apache ausgeliefert werden einbinden

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.