Multi-Domain SSL-Zertifikate

Wer selbst Webserver betreibt, die verschlüsselte Bereiche anbieten sollen, kennt sicherlich das folgende Problem:
HTTPS benötigt pro virtuellem Webserver eine eigene IP-Adresse, weil die Verschlüsselung aktiv wird, bevor der Mechanismus greift, der die Unterscheidung von Name Based Virtual Hosts ermöglicht.

Dieses Problem führt dazu, dass man meistens die Wahl zwischen mehr oder weniger schönen Alternativen hat. Da ich in Projekten immer wieder damit konfrontiert bin – und auch privat des Öfteren danach gefragt werde – möchte ich beschreiben, welche Möglichkeiten man mittlerweile hat, um elegant und ohne irritierende Warnmeldungen damit umzugehen.

Multi-Domain SSL-Zertifikate weiterlesen

Postfix und Dovecot mit StartSSL-Zertifikaten

StartSSL stellt eine günstige Möglichkeit bereit, wie man unkompliziert an SSL-Zertifikate kommt.

Allerdings haben die Zertifkate den Nachteil, dass sie ein Chain-Zertifikat benötigen. Sonst bekommen Nutzer trotz eines eigenlich gültigen Zertifikats Warnmeldungen angezeigt.

Weder Dovecot noch Postfix haben für die Chain-Zertifikate eine Konfigurationsoption. Es geht aber trotzdem sehr einfach, wie im Folgenden gezeigt wird.
Postfix und Dovecot mit StartSSL-Zertifikaten weiterlesen

Klartext-Protokolle über SSL-Verbindungen testen

Hat man regelmäßig mit Servern zu tun, kommt man nicht umhin, ab und zu via Telnet auf Protokollebene mit dem Server zu sprechen. Solange das über eine unverschlüsselte Verbindung läuft, funktioniert das auch prima, z.B. bei SMTP, POP3 oder HTTP.

Schwieriger wird es, wenn man eine verschlüsselte Verbindung nutzen möchte oder muss. SSL via Telnet macht man nicht so nebenbei 😉 Muss man erfreulicherweise auch nicht, denn es gibt ja OpenSSL. Dieses kann nicht nur Zertifikate erstellen und signieren, sondern auch als Client für SSL-verschlüsselte Verbindungen dienen. Und da es de-facto überall verfügbar ist, sollte man wissen, wie das funktioniert.

Generell muss bei verschlüsselten Verbindungen unterschieden werden zwischen einer obligatorisch verschlüsselten Verbindung, wie sie z.B. bei HTTPS zum Einsatz kommt, und einer optional verschlüsselten Verbindung, wie sie bei der Kombination von SMTP und STARTTLS möglich ist.

Klartext-Protokolle über SSL-Verbindungen testen weiterlesen

WordPress Multisite mit selbstsignierten Zertifikaten

Wer die Administration von WordPress im Multisite-Modus mit selbstsignierten Zertifikaten betreibt, stößt eventuell auf das Problem, dass Updates von Jetpack nicht funktionieren.
Das liegt daran, dass WordPress schon seit geraumer Zeit SSL Zertifikate streng verifiziert.

Es gibt keine Konfigurationsmöglichkeit, um das abzuschalten, was für die meisten Anwender gut ist.
Für Leute, die selbstsignierte Zertifikate verwenden, ist das aber extrem lästig.

Da Leute, die selbstsignierte Zertifikate verwenden, in der Regel ausreichend Ahnung haben, sei hier kurz ein Patch veröffentlicht, mit dem man diese Verifikation global abschalten kann.

Global heißt wirklich global: Durch diesen Patch wird kein einziges Zertifikat mehr geprüft!

Die Option, SSL-Zertifikate zu verifizieren, wird in der Klasse WP_Http in der Datei wp-includes/class-http.php gesetzt. Die Klasse hat eine Methode request, in der zu Beginn ein Array mit dem Namen $defaults initialisiert wird. In diesem Array gibt es den Key 'sslverify', der mit dem Wert true initialisiert wird. Ändert man diese Initialisierung auf false, ist die Verifikation für SSL-Zertifikate abgeschalten.

Hier der Patch:

diff -Nur wp-includes.orig/class-http.php wp-includes/class-http.php
--- wp-includes.orig/class-http.php     2013-11-02 20:13:38.000000000 +0100
+++ wp-includes/class-http.php  2013-12-28 18:45:24.900418576 +0100
@@ -80,7 +80,7 @@
                        'body' => null,
                        'compress' => false,
                        'decompress' => true,
-                       'sslverify' => true,
+                       'sslverify' => false,
                        'sslcertificates' => ABSPATH . WPINC . '/certificates/ca-bundle.crt',
                        'stream' => false,
                        'filename' => null,

Den Patch habe ich hier veröffentlicht, weil ich öfters danach gefragt werde.
Empfehlen möchte ich die Verwendung eines verifizierbaren Zertifikates mit korrekter Domain.

Referenzen

VMware ESXi mit Nagios überwachen (Update)

Vor einiger Zeit hatte ich eine Anleitung geschrieben, wie man VMware ESXi mit Nagios überwachen kann.
Das funktionierte bis vor kurzem auf wunderbar, aber dann das Update von IO::Socket:SSL auf Version 1.79 und damit die folgende Warnung:


*******************************************************************
Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
together with SSL_ca_file|SSL_ca_path for verification.
If you really don't want to verify the certificate and keep the
connection open to Man-In-The-Middle attacks please set
SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
*******************************************************************
at /usr/lib/perl5/vendor_perl/5.14.2/LWP/Protocol/http.pm line 31

Damit war der ganze Zauber erstmal dahin, denn check_vmware_api.pl meinte nur noch lapidar:


CHECK_VMWARE_API.PL CRITICAL - Server version unavailable at 'https://10.10.10.38:443/sdk/vimService.wsdl' at /usr/lib/perl5/5.14.2/VMware/VICommon.pm line 545, line 2

Heute habe ich einen Patch für das nagios-plugins-op5-Paket im Build Service bereitgestellt, das dieses Problem löst.

Bisher bestand die Lösung darin, LWP mitzuteilen, dass es auf die Verifikation des Hostnamens verzichten sollte:

$ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;

Nach dem Update von IO::Socket::SSL muss man zusätzlich noch folgenden Code ausführen, um die Verifikation tatsächlich abzuschalten:

require IO::Socket::SSL;
IO::Socket::SSL->import();
IO::Socket::SSL::set_ctx_defaults( SSL_verify_mode => 0 );

Das ESXi Plugin für openSUSE ist hier im Build Service zu finden.

Referenzen

CAcert.org Zertifikate in openSUSE

openSUSE Heute hatte ich das Problem, die CAcert.org CA für curl nutzbar zu machen… Leider findet man dazu rein gar nichts im Internet.

Naja, der Trick, CAcert.org allen auf OpenSSL basierenden Anwendungen bekannt ist relativ einfach:

Man lädt die Zertifikate root.crt und class3.crt im PEM-Format von CAcert.org und speichert sie als ca-root.pem und ca-class3.pem im Verzeichnis /etc/ssl/certs.

Anschließend führt man als root folgendes Kommando aus:

c_rehash

Jetzt werden die Hash-Links auf die neu installierten CA angelegt und das war’s schon!