Insgesamt nutze ich die fb-App auf meinem Phone eher selten, so kann ich gar nicht recht sagen, wann das begann: irgendwann zum Ende des vergangenen Jahres verlernte mein HTC Desire, wie man sich bei fb anmeldet. Nach einem Versuch, die fb-App zu de- und dann reinstallieren ging gar nichts mehr, auch kein Upload von Fotos. Gelegentlich sah ich eine Fehlermeldung, Zertifikat ungültig. Ach ja, mein Phone ist gerooted mit einem LeeDroid.

Tante Google fand mir eine Lösung: es müssen neue Zertifikate installiert werden. Danach geht's wieder.

ownCloud - halb und halb

Monday, January 28. 2013

Das folgende ist schon etwas alt, es gibt einen neuen Artikel mit meinen jüngeren Erlebnissen mit OC 5.+ 

In einem anderen Artikel habe ich ownCloud schon mal kurz erwähnt als eine mögliche Alternative zu Cloud-Angeboten wie GoogleDrive, Dropbox oder Insync. Es gibt ja ganz verschiedene Nutzungs-szenarien für Cloud-Speicherplatz, mein Schwerpunkt liegt nun nicht auf externem Backup-Space oder Sharing sondern auf einem Zugriffsfenster für im Lan vorgehaltene Dateien, das mir orts- und deviceübergreifend zur Verfügung steht. 

Und besonders geht es mir da um die An- und Einbindung meines Androidphones. 

  • schnell mal ein Bild hin- oder herschieben, USB anstöpseln und warten, bis endlich die sd-Karte gemounted ist - und dann für laufende Apps auf dem phone leider nicht mehr zugägnlich ist - dauert mir einfach zu lange.
  • irgendwo unterwegs will ich ein bestimmtes Lied aus meiner Musiksammlung, das ich gerade nicht auf der Sdkarte habe
  • meine mindmaps brauche ich immer und überall und zwar konsistent, also nicht das letzte Edit leider nur auf dem anderen Rechner...

So, das umreisst den Bereich, den mir ownCloud auf einem Rechner im Lan locker erfüllt. Einen dynamischen DNS-Dienst braucht es, der die je aktuelle IP meines DSL an eine Domain bindet, einen von aussen erreichbaren Rechner mit Apache, php, optional mysql und dem aktuellen ownCloud installiert und dann ist es noch sehr sinnvoll, sich für diese Domain eines der kostenlosen Serverzertifikate von startssl zu besorgen. Man kann die php - Dateien des ownCloud direkt in die Document root eines vhost entpacken, für die aktuelle Version 4.51 gibt es aber auch ein debian-repository und auf Sicht ist das doch die viel unaufwendigere Lösung, sobald es updates einzuspielen gilt. (Es gibt packages für CentOS, debian, fedora, openSuSe, RHEL, SLE und Ubuntu.)

Für debian Squeeze importiert man den repository key mit 
wget http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_6.0/Release.key
apt-key add - < Release.key 

bindet das repository ein mit echo 'deb http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_6.0/ /' >> /etc/apt/sources.list.d/owncloud.list
und anschliessend reicht ein

apt-get update
apt-get install owncloud

Fein, jetzt findet man in /var/www/owncloud das ganze php und in /etc/apache2/conf.d/ die Datei owncloud.conf, die man sich evtl. noch etwas zurechtbiegen will. 
Bei mir sorgt ein  

<IfModule mod_alias.c>
   Alias /cloud /var/www/owncloud/
</IfModule>
dafür, dass ich owncloud in jedem vhost als /cloud erreiche.
 
https://meineDomain.tld/cloud im browser ansteuern, die Installation mit ein paar Einstellungen (Datenbank, Verzeichnispfade und Zugriffsoptionen) auf den Weg schicken, Admin und user account anlegen, fertig. 
Auf dem Android gefällt mir als Client der TotalCommander mit WebDav-Plugin sehr gut aber es gibt natürlich zahllose Alternativen.
 
Soweit so gut, die Kategorie Dateien (mit den zwei Filteransichten Musik und Bilder) gefällt. Was mir nicht gefällt sind Kalender und Kontakte. Ich würde eben gerne meinen Androiden von Google und den Google-Account Features ablösen, aber dazu brauche ich für Kontakte und Kalender entsprechende Funktionalität und saubere Importfunktionen, die die derzeit auf Google eingestellten Daten ohne Verluste übernehmen können.
 
Meine Kontakte sind auf https://www.google.com/contacts/#contacts gepflegt, das Gros hat Portraitbilder, die Kontakte sind in Gruppen (bzw getagged), vielfach gibt es Notizen. Ich will jetzt nicht die Kontakte als vcard transferieren und anschliessend alle Portraits händisch neu zuordnen müssen und auf die Tags und einfache Gruppierung völlig verzichten mag ich noch weniger.
 
Bei den Kalendern habe ich noch nicht so detailliert herumprobiert aber soviel ist klar: das Modul CloneGoogleCalendar fehlt auch hier.

Mennoh! Das ist ein Millionenmarkt von Leuten, die nur mit Bauchschmerzen ihre ganzen Kontakte und Kalenderdaten bei google in den USA vorhalten - warum wagt das keiner, die Google-Dienste hierzu nachzubauen und uns Datensparsarmkeit zu ermöglichen? 

Ein Blog mit weiteren Artikeln zu dem Themenkreis sei hier noch empfohlen: netbunker

Noch ein paar pointer auf bezügliche Apps, die man sich auch gut aus f-droid installieren kann:

OwnCloud client - (a few bucks, open source, free if you build it yourself) sync files with OwnCloud.
CardDav-sync - (a few bucks, open source, free if you build it yourself) sync contacts with OwnCloud into your contact managers.
CalDav-sync - (a few bucks, open source, free if you build it yourself) sync calendars in OwnCloud into your calender apps.
Just Player - (freeware, open source) sync music with OwnCloud and play it.

update Ende Februar 2013:
Nun will ich es nach etwas Abstand mal zum Transfer einer kleinen Datei nutzen und - mobile client wie Browser geben alle Anzeichen eines Server Errror. Im error_log findet sich
PHP Fatal error:  xcache_clear_cache(): xcache.admin.user and/or xcache.admin.pass settings is not configured. Make sure you've modified the correct php ini file for your php used in webserver. in /var/www/owncloud/lib/cache/xcache.php on line 50

Na super. Tante Google weiß Rat, scheints habe ich mit dem letzten update && upgrade auf eine Version von owncloud (4.5.7-1) upgedated, die eine Version von xcache erwartet, die unter Debian Squeeze eben nicht gegeben ist. Die empfohlene Abhilfe, die auch hier ownCloud wieder ans Laufen bringt: 

/etc/php5/apache2/conf.d/xcache.ini mit einem Editor meines Vertrauens editieren und dort diese Zeile ergänzen: xcache.admin.enable_auth = Off

Half. OwnCloud ist wieder am Start. Aber im Log stehen nun vieleviele Kopien von: PHP Warning:  xcache_isset(): xcache.var_size is either 0 or too small to enable var data caching in /var/www/owncloud/lib/cache/xcache.php on line 39 Letztlich Log-Spam, eine Applikation sollte wirklich mitbekommen, dass sie eine Warnung schon einige hundert Mal gegeben hat und irgendwann die Frequenz reduzieren, statt bei Benutzung nun rund 4 bis 5 Mal / sec den immergleichen Text ins Log zu schiessen.

 

update 14.3.2013:
nice! heise berichtet von der eben erschienenen Version 5.0 von ownCloud und deutet auf laestig klingende upgrade-Methoden. Aber ich hab' es doch im repository... hier reicht ein apt-get update && ap-get upgrade und dann erscheint, nach Aufruf der Wolke, ein kurzer Hinweis auf das Upgrade, pling, pling,plong, pling, erfolgreich, weitergeleitet - fertig.
Erstmal login als Administrator, es sind eine Reihe neue Applications dazugekommen und ich aktiviere tasks - Antivir hat zwar die Anmerkung "recommended", schmeisst mir aber gleich eine Fehlermeldung. 
Auf den ersten Blick kommt mir die neue Oberfläche etwas dunkler vor, platzsparender und bedienbarer.
Raus und zweites Login als user, ich bekomme erst einmal minutenlang einen Verlaufsbalken mit dem Titel: "Dateisystem-Cache wird aktualisiert ..." Und dann: "Alles leer - lade etwas hoch!" :-(  - da ist schon mal was verlorengegangen. Hoffentlich nur der Link...

Kurz mal durch die anderen Optionen:
Kontakte kennt auf einmal Gruppen! Schon mal ein Schritt in die richtige Richtung.
Aufgaben kennt keine hierarchischen Beziehungen zwischen tasks, also kein "Kapitel 1" .. "Kapitel n" als subTasks zu "Buch". Eine Task hat Title, Kategorie, Ort, Fälligkeit, Fertigstellung scheint Boolean zu sein. Nach Priorität kann man sortieren, aber wo man die setzt, sehe ich erst mal nicht.

Ein Blick in's forum.owncloud.org/ bestätigt, dass andere die Probleme (Dateien, Task/Priority) auch haben. 
Es findet sich auch ein Hinweis auf ein Google import app

die eigene Certificate Authority mit XCA

Saturday, February 18. 2012

 Für eine Gruppe Rechnern in einem Intranet sollen für https Zertifikate erstellt werden. Alle Systeme sind unter mehr als einer Domain erreichbar, die Zertifikate sollen jeweils für alle Namen gültig sein. 'Echte', also von einer in den Browsern vorinstallierten CA signierte Zertifikate scheiden aus Kostengründen aus, Um nicht für jeden einzelnen Rechner eine Ausnahme in den Browsern speichern zu müssen setze ich eine eigen CA auf und signiere die einzelnen Zertifikate mit diesem CA-Zertifikat. Es reicht dann, dieses eine Zertifikat in den browsern zu importieren und alle damit signierten Zertifikate werden grün.

Man kann das natuerlich 'händisch' mit openssl allein machen, aber die Verwaltung wird leicht unübersichtlich. Ich habe XCA genommen, ein 'x509 Certification Authority management tool based on QT4', dass ich auf debian squeeze / KDE mit apt-get install xca installierte.

XCA hat Reiter für Schlüssel, Unterschriftsanfragen, Zertifikate, Rücknahmelisten und Vorlagen. Diese Vorlagen sind XCA-spezifisch, man kann sie neu erstellen aber auch bestehende Zertifikate oder Unterschriftsanfrage in eine Vorlage exportieren. Das ist in der Praxis eine ziemliche Hilfe und erspart Abtippen, für eine neues Request wählt man dann einfach im Reiter Herkunft unten das passende Template und traegt dessen Werte mit Übernehmen ein, anschliessend ändert man nur das, was wirklich neu muss.

Bei der Erstellung des CA-Zertifikates muss man darauf achten, im Reiter Erweiterungen in den Grundbeschränkungen als Typ Zertifikats Authorität einzustellen, Kritisch markieren, im Reiter Key Usage müssen links Certificate Sign und CRL Sign markiert sein, im Reiter Netscape markiert man SSL CA, S/MIME CA und Object Signing CA.

Bei den Zertifikaten für mehr als einen Domainnamen ist das entscheidende Feld im Reiter Erweiterungen die Zeile subject alternative name, hier auf Bearbeiten klicken und in dem Formular links oben DNS und rechts daneben den ersten Namen, mit Hinzufügen eintragen. Das wiederholt man nun der Reihe nach für jeden Namen, für den das Zertifikat gelten soll, auch für den schon auf dem vorigen reiter eingetragenen common name. Es ist wohl so, dass, wenn das Feld subject alternative name im Zertifikat gesetzt ist, nur die dort eingetragenen Werte gelten. Bei Key Usage muss man noch darauf achten, dass im rechten Feld auch TLS Web Server Authentication markiert ist, sonst bekommt man (in FireFox, der da auskunftsfreudiger ist als etwa Chrome) den Fehler SEC_ERROR_INADEQUATE_CERT_TYPE."The rule is that IF a server cert contains an extended Key Usage extension, then it MUST include the extended usage for server authentication."

bekommt man den Fehler sec_error_unknown_issuer zu sehen, muss man an die erzeugten Zertifikate das Zertifikat der signierenden CA anhängen, für server, die alles in einer datei wollen (so Courier) etwa per 

cat domain.tld.{key,crt} my-own-CA.crt >domain.tld.pem

 Bei Webmin zb geht beides, man kann eine wie oben erzeugte combo als keyfile in /etc/webmin/miniserv.conf eintragen, oder dort nur den key selbst und die Zertifikate als certfile= und extracas=

Zertifikate: für Thunderbird

Friday, February 18. 2011

Signierte oder verschlüsselte emails versenden, mit Thunderbird und startcom - Zertifikaten: eines dieser Art bekommt man ja direkt bei der startCom - Anmeldung im Browser installiert, und man kann sich nach Belieben weitere S/MIME Client -Zertifikate für weitere email-Adressen erzeugen. 

Die Schrittfolge ist, auf startssl.com, recht schnell durchlaufen: im Validation Wizard wählt man Email Address Validation, dann eine Adresse zur Validierung eintragen, es kommt eine Mail an diese Adresse mit einem Code, den man wieder in dem Formular auf der Webseite einsetzt. Ein Klick auf Finish und nun findet man diese Adresse unter dem Reiter 'Email Validations' gelistet. 

Wechseln zum Certificates Wizard, der S/MIME gleich als default-Option hat, continue , und das koennen wir auch gleich bei der nächsten Seite (Schlüssellänge: hochgradig) klicken.

Es dauert einen Moment, während der Server bei startCom einen privaten Schlüssel generiert. Hmm, im Unterschied zur Generierung der SSL/TLS-Server certificates gibt es hier keine Option, einen selbstgenerierten privaten Schlüssel anzugeben.

In der folgenden Maske kann man aus der Menge der bislang unbedienten validierten email-Adressen eine auswählen, continue, es dauert einen Moment und dann meldet ein Popup, dass das Zertifikat im Browser installiert wurde.

Dies Zertifikat muessen wir jetzt aus dem Browser (bei mir ein Firefox/3.5.16) an einen sicheren Ort im Dateisystem und von dort hinein in Thunderbird transferieren. Der erste Schritt ist bei mir unter Bearbeiten/Einstellungen/erweitert/Verschlüsselung/Zertifikate anzeigen erreichbar, ich wähle einen der Einträge unter StartCom Ltd. aus.Mit Ansehen/Details kann man sich vergewissern, das richtige erwischt zu haben, die mail-Adresse ist als Zertifikatsgegenstand-Alternativ-Name verzeichnet. Ein Klick auf "Sichern", wenn man mehr als eine Adresse mit Zertifikaten ausruesten moechte, empfiehlt sich ein sprechender Dateiname. Nun werden Passworte abgefragt, zuerst, falls man es einsetzt, das Master-Passwort, mit dem Firefox das Sicherheitsmodul schützt und anschliessend legt man für das zu speichernde Zertifikat ein Zugangspasswort an.  Wenn man es recht bedenkt, hängt an diesen Passworten das ganze Sicherheitsversprechen des Zertifikats.

 Damit können wir den Firefox - Zertifikatsmanager schliessen und Thunderbird zum Import der Zertifikate öffnen. Edit/Preferences/Advanced/Certificates/View Certificates öffnet den Certificate Manager, unter dem Reiter 'Your Certificates' werden ggf schon vorhandene Zertifikate gelistet und auf diesem Blatt findet sich auch der Button "Import". Im Dateiauswahl-Dialog navigieren wir zum eben abgespeicherten Zertifikat und öffnen es, wieder wird erst das Master-Passwort und danach das Zertifikatspasswort abgefragt und dann ist es drin.

 Damit Thunderbird die Zertifikate nun auch nutzt, müssen sie mit bestimmten Accounts verbunden werden, dazu geht man in den Account Settings auf 'Manage Identities', markiert hier in der Liste von (ausgehenden) email-Adressen die, für die das Zertifikat ausgestellt wurde, und klickt dann Edit/Security. Unter "Digital Signing" klickt man 'Select' und hat nun oben eine Auswahl der installierten Zertifikate, zu denen darunter jeweils die wesentlichen details angezeigt werden. Hat man das rechte erwischt und klickt OK folgt die Abfrage, ob man das gleiche Zertifikat auch für verschlüsselte Mailkorrespondenzen nutzen will. Hier zustimmen und dann wird das Zertifikat auch in der Zeile Encryption eingetragen. Jetzt noch ein Häkchen bei 'Digitally sign messages (by default) und dann kann man die offenen Dialog allesamt mit OK schliessen. 

Derart signierte Mails schicken die Nachricht immer noch im Klartext durchs Netz, die Signatur garantiert nur, dass die Nachricht auf dem Wege nicht verändert wurde. Aber gleichzeitig verteilt man auf diese Art den öffentlichen Schlüssel des eigenen Zertifikates an die Empfänger, und schafft damit die Voraussetzung für die zweite Funktion, verschlüsselte Mails.
Verschlüsselte Korrespondenz ist zwischen Mailpartnern möglich, die beide ein gültiges Zertifikat installiert haben und jeweils auch den öffentlichen Schlüssel des anderen kennen. Welche Schlüssel der eigene Mailer schon kennt, listet Thunderbird im Certificate Manager unter dem Reiter 'People'.

Kostenlose S/Mime-Zertifikate  bekommt man nicht nur von startCom, mozillazine listet und diskutiert Alternativen. Mehr Infos zu Mailverschlüsselung und S/Mime. Statt mit S/Mime kann man auch mit OpenPGP verschlüsseln aber die beiden Protokolle verstehen einander nicht.

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

Alternative Anleitung mit Beispielen für nginx, Lighttpd, Postfix, Dovecot, eJabberd, vsftpd

 

 

 

 

(Page 1 of 1, totaling 5 entries)