StartSSL Zertifikate erneuern

Neues Certificate Signing Request erstellen (mit vorhandenem privaten Schlüssel)

openssl req -new -key ~/stephangsell.de.key -out ~/stephangsell.de.csr

Dann bei StartSSL den Inhalt der CSR-Datei hochladen und auf unterzeichneten Schlüssel warten.
Schlüsselinhalt in ~/stephangsell.de.crt speichern.

Folgende 3 Befehle sind nur beim ersten Mal notwendig, um eine gültige StartSSL-Zertifikatskette zu erzeugen

wget https://www.startssl.com/certs/ca.pem
wget https://www.startssl.com/certs/sub.class1.server.ca.pem
cat sub.class1.server.ca.pem ca.pem > startssl_alles.pem

UPDATE April 2016: Mittlerweile bekommt man bei StartSSL eine ZIP-Datei mit dem eigentlichen Zertifikat als .crt-Datei sowie einer Datei namens root_bundle.crt. Diese wird als ~/startssl_root_bundle.crt gespeichert.

Anschließend

cp ~/stephangsell.de.crt /etc/ssl/certs/ && cp ~/stephangsell.de.key /etc/ssl/private/
cp ~/startssl_root_bundle.crt /etc/ssl/pem/
cat ~/stephangsell.de.key ~/stephangsell.de.crt > /etc/ssl/pem/stephangsell.de.pem
cat /etc/ssl/pem/stephangsell.de.pem /etc/ssl/pem/startssl_root_bundle.crt > /etc/ssl/pem/stephangsell.de.startssl_alles.pem
systemctl restart apache2.service ; systemctl restart postfix.service ; systemctl restart dovecot.service 

owncloud + lighttpd: „413 – Request Entity Too Large“

Obiger Fehler führte dazu, dass in ownCloud keine größeren Dateien hochgeladen werden konnten.
Das Problem war leicht zu beheben, da nur der entsprechende Ordner fehlte, in dem lighttpd seine hochzuladenden Dateien zwischenspeichert.

Er wird so angelegt und anschließend schreibbar für den Benutzer www-data gemacht:

mkdir -p /var/cache/lighttpd/uploads
chown www-data:www-data /var/cache/lighttpd/uploads

lighttpd, ownCloud, FolderSync: 417 und Expectation Failed

Seit einiger Zeit hatte ich beim Synchronisieren zwischen ownCloud und Android-Telefon mit FolderSync das Problem, dass ich vom Telefon aus keine neuen Dateien in meine ownCloud hochladen konnte.
Fehlermeldung in FolderSync: ‚Expectation Failed‘.

Im lighttpd-access.log fand ich folgende Zeile:

89.XXX.XXX.XXX - - [17/Dec/2013:06:49:23 +0100] "PUT /remote.php/webdav/testdatei HTTP/1.1" 417 363 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"

Lösen lässt sich das Problem, indem in der Datei /etc/lighttpd/lighttpd.conf folgendes eingefügt wird:

server.reject-expect-100-with-417 = "disable"

Quelle: https://groups.google.com/forum/#!topic/tacitdynamics/k1MssqqVWYc

Debian 6 Squeeze: openssl 1.0.1e und lighttpd 1.4.33 selbst kompilieren (für TLS 1.2 mit PFS)

Nach den ganzen Geschichten um die NSA wollte ich dann meinen Webserver auch mal etwas besser absichern.

Dazu habe ich für den bei mir eingesetzten lighttpd hier eine Anleitung gefunden.

Problem ist allerdings, dass die meisten Chiffre mit der in Debian Squeeze eingesetzten openssl-Bibliothek in der Version 0.9.8o leider nicht funktionieren. Die Lösung: eine neue openssl-Version muss her. Aktuell (Stand November 2013) ist die Version 1.0.1e.

Dank Server4You und dem dort eingesetzten vServer bin ich leider auf das mittlerweile veraltete Debian 6 (Squeeze) angewiesen und kann mangels Unterstützung durch die Server4You-Host-Server nicht auf Wheezy aktualisieren. Deshalb bleibt uns nichts anderes übrig, als die notwendigen Pakete selbst zu kompilieren.

Damit lighttpd (lighty) auch mit der neuen openssl-Version umgehen kann, werden wir die derzeit letzte lighty-Version 1.4.33 runterladen und selbst kompilieren.

Ich gehe hier davon aus, dass lighttpd und openssl bereits aus den normalen apt-Quellen installiert sind.

Zunächst zu openssl:

apt-get build-dep openssl
wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
cd openssl-*
unp openssl-1.0.1e.tar.gz
./config shared zlib-dynamic
#so sähe die config-Zeile für den vollständigen Debian-openssl-Ersatz aus:
#./config --prefix=/usr --openssldir=/etc/ssl --libdir=lib shared zlib-dynamic
make
make test

#ohne den folgenden Befehl läuft checkinstall nicht durch
mkdir -p /usr/local/ssl/lib/engines

Das .deb-Paket erstellt nun checkinstall. Allerdings ändern wir den Paketnamen, damit wir nicht mehr der originalen Debian-openssl-Installation ins Gehege kommen:

checkinstall -D --pkgname openssl-pfs

Da wir die neue openssl-Version in /usr/local/* installieren, muss die originale Debian-Version nicht deinstalliert werden, d.h. wir können es einfach parallel installieren:

dpkg -i openssl_1.0.1e-1_i386.deb

Jetzt kann es mit lighttpd weitergehen. Wir sorgen zunächst dafür, dass alle Build-Abhängigkeiten von Debian gelöst werden:

apt-get build-dep lighttpd

wget http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.33.tar.gz
unp lighttpd-1.4.33.tar.gz
cd lighttpd-*
./autogen.sh
./configure --with-openssl --with-openssl-libs=/usr/lib --prefix=/usr --with-webdav-props --with-webdav-locks

#neues .deb-Paket erstellen
checkinstall -D

#alte Debian-Skripte sichern
cp -r /usr/share/lighttpd/ /root/usr_share_lighttpd

#die aktuelle lighttpd-Installation entfernen
apt-get remove lighttpd

#alte Debian-Skripte wiederherstellen 
#(da diese durch die Deinstallation verloren gegangen sind)
cp -r /root/usr_share_lighttpd /usr/share/lighttpd

Jetzt können wir endlich das gerade erstellte lighty-Paket installieren:

dpkg -i lighttpd_1.4.33-1_i386.deb

Mit einem

service lighttpd restart

starten wir den neu kompilierten Webserver. Danach sollten wir mal testen, ob alle Webseiten noch klappen 😉

Falls ja, können wir den Autostart von lighty wieder einrichten:

update-rc.d lighttpd defaults

Jetzt können wir endlich unsere Konfiguration so anpassen, dass der Webserver mit sicheren Chiffre und Perfect Forward Secrecy (PFS) arbeitet:

ssl.use-sslv2 = "disable"
ssl.use-compression = "disable"
ssl.honor-cipher-order = "enable"
ssl.cipher-list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:RC4-SHA"

Oder Alternativ komplett ohne Unterstützung für RC4 (dadurch keine Unterstützung für Java und IE unter Windows XP):

ssl.cipher-list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA"

UPDATE 20.01.2014:
Das funktioniert natürlich auch mit lighttpd Version 1.4.34 genauso. Einfach oben immer 1.4.33 ersetzen durch 1.4.34.

Postfix: 535 Authentication credentials invalid

Ich verwende Postfix, um per Relay E-Mails über Web.de zu verschicken.
Das klappte bisher auch problemlos, bis ich die Fehlermeldung bekam:

postfix/smtp[11477]: SASL authentication failed; server smtp.web.de[213.165.67.124] said: 535 Authentication credentials invalid

Nach einem Einloggen auf Web.de und dem Verschicken einer Mail an einen beliebigen Empfänger übers Webinterface, klappte auch, ohne Änderung an meiner Postfix-Konfiguration, wieder das Verschicken von E-Mails über Postfix.

Klingt komisch, ist aber so!

=================================
EDIT:
Es kommt noch schlimmer. Nachdem auch die Vorgehensweise von oben nicht mehr klappte, habe ich festgestellt, dass Web.de einfach so meinen POP3/IMAP-Zugang „sicherheitshalber“ deaktiviert hat. Dies hat Web.de in einer Mail angekündigt. Zum Reaktivieren muss man folgendes in der Weboberfläche durchführen:
https://hilfe.web.de/e-mail/einstellungen.html#pop3-imap

Postfix und TLS

Damit die TLS-Zertifikate der Gegenstellen akzeptiert werden, müssen die CA-Zertifikate bekannt sein.
Dazu wird in der Datei /etc/postfix/main.cf folgende Zeile eingefügt
smtp_tls_CApath = /etc/ssl/certs/

Damit die Zertifikate auch erkannt werden, müssen sie vorher gehasht werden:
c_rehash $(postconf -h smtp_tls_CApath)

Zum Schluss noch ein
service postfix restart

Da postfix unter Debian allerdings in einer chroot-Umgebung läuft, muss der smtp_tls_CApath vor dem postfix Start in den chroot-Ordner (/var/spool/postfix) kopiert werden. Dies geschieht am einfachsten, wenn man in der /etc/init.d/postfix folgendes abändert (ab Zeile 77):

#               # if we're using tls, then we need to add etc/ssl/certs/ca-certificates.crt.
#               if [ -f "/etc/ssl/certs/ca-certificates.crt" ]; then
#                   smtp_use_tls=$(postconf -h smtp_use_tls)
#                   smtp_enforce_tls=$(postconf -h smtp_enforce_tls)
#                   smtpd_use_tls=$(postconf -h smtpd_use_tls)
#                   smtpd_enforce_tls=$(postconf -h smtpd_use_tls)
#                   case :$smtp_use_tls:$smtp_enforce_tls:$smtpd_use_tls:$smtpd_enforce_tls: in
#                       *:yes:*)
#                           mkdir -p etc/ssl/certs
#                           cp /etc/ssl/certs/ca-certificates.crt etc/ssl/certs/
#                   esac
#               fi

                # if we're using CApath, we need to copy the whole directory
                ca_path=$(postconf -h smtp_tls_CApath)
                if [ "X$ca_path" != "X" ]; then
                        /usr/bin/c_rehash $(postconf -h smtp_tls_CApath) > /dev/null
                        # strip leading /
                        ca_path="${ca_path#/}"
                        # delete current copy
                        [ -d ${ca_path} ] && rm -rf ${ca_path}
                        mkdir -p ${ca_path}
                        if [ -d /${ca_path} ]; then
                                # copy hashes and dereference
                                cp -L /${ca_path}/*.0 ${ca_path}/
                                chmod -R a+rX ${ca_path}
                        fi
                fi

Quelle: http://bugs.debian.org/287795.

SSL-Zertifikate von startssl

Certificate Signing Request (CSR) für startssl.com erstellen:
openssl req -new -key stephangsell.de.key -out stephangsell.de.csr

Für lighttpd muss eine PEM-Datei erstellt werden, die den privaten und öffentlichen Schlüssel in einer Datei enthält:
cat /etc/ssl/private/stephangsell.de.key /etc/ssl/certs/stephangsell.de.crt > /etc/ssl/pem/stephangsell.de.pem

Mehr Infos hier.

Mailman: neue Subdomain

Kürzlich musste ich die Subdomain für den administrativen Zugriff auf Mailman ändern.

Dazu zuerst in der Datei /etc/mailman/mm_cfg.py folgende Zeile anpassen:
DEFAULT_URL_HOST = 'sub1.example.org'

Damit anschließend Links auf den Mailman-Seiten funktionieren, müssen diese an die neue Subdomain angepasst werden mittels
withlist -l -r fix_url <listenname>

SSH-Zugang ohne Passwort per Public-Key-Authentifizierung

Hier habe ich einen netten Einzeiler dazu gefunden, der auch noch auf das mounten entfernter Verzeichnisse per sshfs eingeht.

Zunächst mit

ssh-keygen

ein (passwortloses) RSA-Schlüsselpaar erstellen.

Dann einmal mit

cat ~/.ssh/id_rsa.pub | ssh user@server 'cat >>~/.ssh/authorized_keys'

auf dem Server einloggen.

Update: Alternativ macht dieser Befehl das gleiche:

ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

Beim nächsten Zugriff per

ssh user@server

ist dann auch kein Passwort mehr notwendig.

Postfix, Dovecot und virtuelle Domains (ohne SQL-Datenbank)

Meinen E-Mail-Server habe ich teilweise nach der ISP-Mail-Anleitung eingerichtet. Da mir aber die dort vorgeschlagene Einrichtung mittel mysql-Datenbank zu aufwendig erschien, habe ich es etwas abgewandelt.

Zu einer bestehenden Domain sollte eine weitere hinzukommen, die jedoch E-Mails nur weiterleitet (es soll aber auch möglich sein, E-Mails mit dieser Domain zu verschicken). Dazu wird in die Datei /etc/postfix/main.cf
folgendes eingefügt:

virtual_alias_domains = anderedomain.de
virtual_alias_maps = hash:/etc/postfix/virtual

Letztere Datei (/etc/postfix/virtual) hat dabei folgenden Inhalt, womit eine Weiterleitung auf  beispiel@example.org eingerichtet wird.

info@anderedomain.de     beispiel@example.org

Soweit so gut. Mails an info@anderedomain.de werden nun weitergeleitet an beispiel@example.org.

Nun soll es auch möglich sein, E-Mails unter dem Namen info@anderedomain.de zu verschicken. Da die Authentifizierung bei Postfix über SASL von Dovecot eingerichtet ist, und kein Linux-Systemnutzer für die E-Mail-Adresse eingerichtet werden soll, eine Datei mit einem ähnlichen Schema wie /etc/passwd angelegt.

/var/vmail/conf/benutzerdb:

info@anderedomain.de:{plain}passWORT

Für einen ersten Test sollte das ausreichen. Sicherer ist natürlich, nur den MD5-Hash des Passwortes zu speichern. Dieser lässt sich hier berechnen. Für obiges Passwort würde entsprechend die Datei dann so aussehen:
info@anderedomain.de:{MD5}30b9de8ee60962fec6006a1ac474b733

Die Passwortdatei muss nun noch Dovecot bekannt gemacht werden. In der Datei /etc/dovecot/dovecot.conf wird dazu folgendes eingetragen:

passdb passwd-file {
args = /var/vmail/conf/benutzerdb
}

Dadurch kann sich ein E-Mail-Client gegenüber dem Server authentifizieren, ohne dass ein Linux-Benutzer angelegt werden musste.