Sonntag, 25. Mai 2014
Wenn lftp auf Grund von Zertifikatsproblemen bockt …
Certificate verification: subjectAltName does not match »domain.tld«
… wechselt man folgendermassen auf unsichere FTP-Verbindungen:
$ lftp -e 'set ftp:ssl-allow off; cd public_html; put index.php; bye' www.domain.tld
Via: Lftp Fatal Error: Certificate Verification: Not Trusted
Tags: Certificate, How-To, lftp, Zertifikate
Labels: Linux
Donnerstag, 4. Oktober 2012
Irgendwie hat es Lotus Notes auf der Arbeit (von mir auch schon liebevoll als „a pile of shit“ bezeichnet) so an sich, dass es so seine Problem mit Private Public-Key-Verschlüsselung hat. Zugegebenermassen habe ich selber auch noch nicht ganz durchblickt, was jetzt was ist — und wann man von Public-Key-Verschlüsselung spricht und wann von Zertifikaten.
Mittlerweile habe ich realisiert, dass die Verschlüsselung dann auf Anhieb klappt, wenn ich das X.509-Zertifikat eines Benutzers in dessen Kontakt importiere (über Actions > Certificates > Import Internet Certificate). Doch manchmal hat man das Zertifikat einfach nicht zur Hand, weil es auf Gottes Erde so viele Arten gibt, den Mailverkehr zwischen zwei Parteien zu verschlüsseln.
So wie heute: Da kam also ein Mail an, welches eine smime.p7s-Signatur im Anhang enthielt (nur sichtbar über den Quelltext des E-Mails). Lotus Notes scheint (zumindest bei uns) nichts damit anfangen zu können.
Ich kopierte die Signatur deshalb manuell in eine Textdatei und speicherte diese als smime.p7s ab. Windows erkennt diese Dateiendung leider nicht. Indem ich .p7s in .p7b änderte, wechselte das Icon der Datei in ein Zertifikat. Ich konnte dieses nun Doppelklicken, Microsoft Certificates wurde gestartet und zeigte mir den Inhalt des Zertifikats an.
Mittels Rechtsklick auf das Zertifikat mit dem Namen der Person wählte ich Actions > Export aus. Ich generierte mir auf diese Weise eine DER-kodierte .cer-Datei. Diese legte ich wiederum als Datei auf dem Desktop ab.
Jetzt erst war es dem „dampfenden Scheisshaufen“ (Lotus Notes) möglich, das Zertifikat dem Kontakt hinzuzufügen. Und somit kann ich seither mit der Gegenpartei verschlüsselt kommunizieren, ohne auf eine webbasierte Secure Mail-Lösung zurückgreifen zu müssen.
Kleingedrucktes: Natürlich benötige auch ich ein entsprechendes Zertifikat. Dieses habe ich über Symantec VeriSign bezogen.
Tags: CER, DER, GPG, Lotus Notes, p7b, p7s, PGP, S/MIME, Verschlüsselung, Zertifikate
Labels: IT
Mittwoch, 8. Juni 2011
ACHTUNG: Funktioniert leider doch nicht wie erwünscht.
imapfilter ist das Tool meiner Wahl, um einkommende Mail-Nachrichten in IMAP-Unterordner zu verschieben. Dessen Anwendung habe ich in einem Blog-Artikel erläutert.
Seit mein Arbeitgeber mein E-Mail-Konto von einem Unix-Mailserver auf eine Microsoft Exchange 2010-Lösung migriert hat, gab es Probleme mit den Zertifikaten. (Natürlich hätte ich die Regeln erneut unter Exchange erfassen können, aber der Vorteil von imapfilter ist eben gerade, dass man nur die Serververbindung anpassen muss, und die Mails werden weiter schön sauber sortiert).
imapfilter lässt man bekanntlich beim ersten Verbindungsversuch im interaktiven Modus laufen und akzeptiert dort dann brav das Zertifikat das Mail-Servers:
Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch Server certificate issuer: /C=BM/O=QuoVadis Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis Global SSL ICA Server key fingerprint: CD:10:34:E9:6D:1D:07:09:3D:9E:53:FC:B5:94:B0:10 (R)eject, accept (t)emporarily or accept (p)ermanently? p
Doch leider schien dieser Server in der Folge einfach so den Fingerprint zu wechseln. Als ich imapfilter nach einiger Zeit (und Fehlermeldungen im cron.log) erneut im interaktiven Modus ausführte, erschien folgende Warnung:
Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch Server certificate issuer: /C=BM/O=QuoVadis Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis Global SSL ICA Server key fingerprint: 6D:D9:E8:FF:A3:70:2A:D8:44:10:0C:7D:0E:94:65:FC ATTENTION: SSL/TLS certificate fingerprint mismatch. Proceed with the connection (y/n)? y
Leider führte das Bestätigen der Warnung nicht dazu, dass dieses neue Zertifikat akzeptiert wurde (wohl, weil für denselben Server bereits ein anderes Zertifikat gespeichert war). Meine Vermutung: Da mein Arbeitgeber einen loadbalancierte Exchange 2010-Infrastruktur aufgebaut hat, besitzt jeder Server ein anderes Zertifikat (auch wenn beide gegen aussen als mail.campus.unibe.ch in Erscheinung treten).
Der Workaround sah folgendermassen aus:
$ copy ~/.imapfilter/certificates ~/.imapfilter/certificates.old $ imapfilter -c myconfigfile (... accept certificate permanently ...) $ cat ~/.imapfilter/certificates.old >> ~/.imapfilter/certificates
Ab sofort motzte imapfilter nicht mehr über den gelegentlich wechselnden Fingerprint, weil nun einfach beide möglichen Zertifikate in der Datei gespeichert sind.
Tags: CA, IMAP, imapfilter, PKI, Verschlüsselung, Zertifikate
Labels: Linux
Mario Aeby, geboren am 25. September 1980 in Bern, Schweiz
Ein Weblog über IT (Linux, OSS, Apple), Heim-Automation; mein mittlerweile abgeschlossenes Geschichtsstudium; Erkenntnisse aus meiner aktuellen Tätigkeit in der Informationssicherheit, meine Erfahrungen als IT-Berater, IT-Auditor, Web-Developer und IT-Supporter; die Schweiz, den Kanton Bern, meine ursprüngliche und auch wieder aktuelle Wohngemeinde Neuenegg, meine vorherige Wohngemeinde Bern, über lokale, regionale und globale Politik; meine Reisetätigkeit und Erfahrungen mit anderen Kulturen; und zu Guter letzt auch das Älter werden.
Alle in diesem Blog gemachten Aussagen und Meinungen sind persönlich und nicht als Ansichten meines aktuellen und/oder meiner bisherigen Arbeitgeber zu verstehen.
 |