Entries tagged as zertifikat
Das Smartphone stellt sich bei Facebook blöd
Monday, April 1. 2013
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>
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.
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.
Zertifikate für apache, courier, webmin, postfix, dovecot, nrpe einbinden
Wednesday, February 9. 2011
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