dreckhände

Leider habe ich nicht zurückverfolgen können, was eigentlich den Auslöser davon darstellte, gefühlt schien das K9 - Mail meines android zu spinnen: neu angelegte Unterordner auf dem imap-Server wurden da nicht angezeigt und beim Abruf neuer Nachrichten gab es oft reihenweise Fehlermeldungen (ssl-handshake fail). Alle Versuche, K9 mit veränderten Einstellungen zu heilen, schlugen fehl. 
Bis ich mir dann mal die Zeit nahm, auf den Server zu schauen und dort im mail.log viele Fehlermeldungen wie diese fand:

imapd-ssl: Maximum connection limit reached for (und die IP)

Wobei an dem Server nicht eben viele Clienten hingen, sondern genau zwei: ein Thunderbird und eben K9 auf dem Androiden. Die in den Fehlermeldungen gelisteten IPs liessen sich ohne Zweifel und Ausnahme auf das Android-Telefon zurückführen.
Google lieferte mir einen vergleichbaren Problembericht von jmd., dermit Thunderbird und einem OSX Mail auch diesen Fehler sah und ihn dort auf Mail zurückführte, wie bei mir tauchte die IP des Rechners mit Thunderbird nie auf. Auch dort kam nicht heraus, warum eine anfangs funktionierende Einrichtung dann diese Fehler warf, aber eine Abhilfe habe ich gefunden.

In /etc/imapd-ssl habe ich diese beiden Einträge angefügt:

MAXDAEMONS=280
MAXPERIP=40

noch ein /etc/init.d/courier-imap-ssl restart und seither ist Ruhe und K9 kommt auch wieder klar.

In einem früheren Eintrag hatte ich startssl als Quelle für kostenlose Zertifikate für Server angesprochen, die kostenlosen Class 1 - Zertifikate gelten immer für eine Subdomain und die Domain selbst. Also zB. www.domain.tld und  domain.tld. Hier mein Waschzettel, um das Zertifikat für den Webserver der Domain, Courier (pop3s, imaps) und für die Serververwaltungen Webmin und ISPConfig2 einzubinden.

 
# Verzeichnis für die eigenen Certs anlegen 
mkdir -p  /etc/ssl/certs/startssl/
chmod 700 /etc/ssl/certs/startssl/

# den eigenen key und das von startssl signierte zertifikat hier speichern
# darauf achten bzw. kontrollieren, dass jede dieser Dateien mit einem \n endet
domain.tld.key
domain.tld.crt
chmod 600 domain.tld.key

# die certs von startssl herunterladen
wget https://www.startssl.com/certs/ca.pem
wget https://www.startssl.com/certs/sub.class1.server.ca.pem

# umbenennen ordnet
mv ca.pem startssl.ca.crt
mv sub.class1.server.ca.pem startssl.sub.class1.server.ca.crt

# die ganze Kette zusammenkopieren
cat startssl.sub.class1.server.ca.crt startssl.ca.crt >startssl.chain.class1.server.crt
cat domain.tld.{key,crt} startssl.chain.class1.server.crt >domain.tld.pem
chmod 600  domain.tld.pem

# fuer imap-ssl und pop-ssl eintragen 
# in den beiden .cnf den Pfad zum domain.tld.pem einzutragen funktioniert nicht, 
# courier erwartet das Zertifikat in oder unter /etc/courier
# was dagegen klappt ist ein symlink von dem Zertifikat nach imapd.pem bzw pop3d.pem
mv /etc/courier/imapd.pem /etc/courier/imapd.pem.bkp
mv /etc/courier/pop3d.pem /etc/courier/pop3d.pem.bkp
ln -s /etc/ssl/certs/startssl/domain.tld.pem /etc/courier/imapd.pem
ln -s /etc/ssl/certs/startssl/domain.tld.pem /etc/courier/pop3d.pem

# neu starten
/etc/init.d/courier-imap-ssl stop 
/etc/init.d/courier-imap-ssl start
/etc/init.d/courier-pop-ssl stop
/etc/init.d/courier-pop-ssl start


# fuer webmin eintragen
nano /etc/webmin/miniserv.conf

# dort den eintrag keyfile auskommentieren und stattdessen eintragen:
keyfile=/etc/ssl/certs/startssl/domain.tld.pem

# und neu starten
/etc/init.d/webmin restart


# für ispConfig auf domain.tld:81 einbinden
nano /root/ispconfig/httpd/conf/httpd.conf

# dort auskommentieren
##SSLCertificateFile /root/ispconfig/httpd/conf/ssl.crt/server.crt
##SSLCertificateKeyFile /root/ispconfig/httpd/conf/ssl.key/server.key
ggf. auch #SSLCertificateChainFile und #SSLCACertificateFile

# und stattdessen eintragen:
SSLCertificateFile /etc/ssl/certs/startssl/domain.tld.net.crt
SSLCertificateKeyFile /etc/ssl/private/domain.tld.net.key
SSLCertificateChainFile /etc/ssl/certs/startssl/startssl.chain.class1.server.crt

# neu starten
/etc/init.d/ispconfig_server restart


# für den Apache des betreffenden vhosts in dessen conf gleichermassen eintragen
SSLEngine on
SSLCertificateFile /etc/ssl/certs/startssl/domain.tld.net.crt
SSLCertificateKeyFile /etc/ssl/private/domain.tld.net.key
SSLCertificateChainFile /etc/ssl/certs/startssl/startssl.sub.class1.server.ca.crt

# neu starten
/etc/init.d/apache2 restart


# für postfix
mkdir -p /etc/postfix/ssl/startssl_cert
ln -s /etc/ssl/certs/startssl/domain.tld.crt /etc/postfix/ssl/startssl_cert/domain.tld.crt
ln -s /etc/ssl/certs/startssl/domain.tld.key /etc/postfix/ssl/startssl_cert/domain.tld.key
# 1 Zeile!
ln -s /etc/ssl/certs/startssl/startssl.chain.class1.server.crt 
/etc/postfix/ssl/startssl_cert/startssl.chain.class1.server.crt

# postfix' main.cf editieren und darin einfügen bzw. anpassen:
nano /etc/postfix/main.cf

#TLS Support
## smtpd
smtpd_tls_auth_only = no
smtpd_use_tls = yes

# eigener Key
smtpd_tls_key_file = /etc/postfix/ssl/startssl_cert/domain.tld.key
# eigenes Certificate
smtpd_tls_cert_file = /etc/postfix/ssl/startssl_cert/domain.tld.crt
# public der Certificate Authority
smtpd_tls_CAfile = /etc/postfix/ssl/startssl_cert/startssl.chain.class1.server.crt

smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

##smtp
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes

update:

# fuer dovecot (2.x):
nano /etc/dovecot/local.conf

ssl_cert = </etc/ssl/certs/startssl/domain.tld.crt
ssl_key = </etc/ssl/certs/startssl/domain.tld.key
ssl_ca = </etc/ssl/certs/startssl/startssl.chain.class1.server.crt

#fuer nrpe, bei mir icinga-nrpe-server

nano /etc/icinga-nrpe/nrpe.cfg

cert_file=/etc/ssl/certs/startssl/domain.tld.crt
cacert_file=/etc/ssl/certs/startssl/startssl.chain.class1.server.crt
privatekey_file=/etc/ssl/certs/startssl/domain.tld.key


 
 
 

Ich hatte den seltsamen Effekt, dass von den Merkmalen IPv4/IPv6 und http:/https: alle Permutationen funktionierten bis auf IPv6 mit https. Die Konfiguration der vhosts unter apache2 sah klar und richtig aus, aber sobald ich von http:// auf https:// wechselte, fiel die Verbindung von IPv6 auf IPv4 zurück.

Nun, es war kein Mangel am Startcom - Zertifikat und auch kein Bug des ssl, apache2 oder firefox sondern was fehlte war in ports.conf ein 

Listen 443

Beim Herumtesten kam mir noch ein anderer 'falscher Fehler' unter:
Bei einer adhoc ssl-isierten Domain monierte firefox "ssl_error_rx_record_too_long" und apache schrieb ins error_log "[error] [client 192.168.1.100] Invalid method in request \x16\x03\x01". Tatsaechlich müßte der Text der Fehlermeldung besser lauten: "Your SSL configuration is crap"denn es fehlten für den :443 - vhost die Zeilen mit SSLEngine, SSLCertificateFile, SSLCertificateKeyFile etc.

Verschlüsselte Verbindungen machen Sinn, auch wenn man keinen WebShop betreibt oder eine Bank ist. Die Passwörter beim Zugriff auf die Mail oder die Daten im geschützten Kundenbereich möchte man schon vor cachenden Proxies oder einem lauschenden wireshark verborgen halten - aber dazu braucht es Zertifikate. 

Die kann man sich zwar ohne grosse Mühe selber erstellen und signieren, aber solchen Eifer bestrafen die Browser, namentlich FireFox, mit so eindrucksvollen Warnhinweisen, dass 'normale' Nutzer unweigerlich den Eindruck bekommen, die Verschlüsselung sei das Sicherheitsrisiko.

Und 'echte' Zertifikate sind zu teuer. Mit einer Ausnahme: startssl.com, da bekommt man  Serverzertifikate für je eine Domain und eine Subdomain umsonst. Geht ganz leicht, heise hat im Zweifel aber auch eine handliche Anleitung dazu.

 Es empfiehlt sich nur, wenn man postgrey auf dem mail server hat, startcom.org in die whitelist einzutragen, sonst muss man den Validierungsprozess wieder und wieder beginnen.