Posts Tagged ‘OpenSSL’

Samstag, 2. April 2016

monit mit MacPorts unter OS X El Capitan installieren (mit angeblich fehlenden OpenSSL-Headern)

Vor einigen Tagen habe ich mich entschieden, mein MacBook Air (Late 2010) komplett platt zu machen und OS X El Capitan darauf zu installieren.

Nach der Neuinstallation musste ich auch alle meine MacPorts-Packages neu installieren. Leider gab es Probleme bei der Installation des Pakets monit:

$ sudo port install monit
Password:
---> Computing dependencies for monit
---> Configuring monit
Error: Failed to configure monit, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1/config.log
Error: org.macports.configure for port monit returned: configure failure: command execution failed
Please see the log file for port monit for details:
   /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log
To report a bug, follow the instructions in the guide:
   http://guide.macports.org/#project.tickets
Error: Processing of port monit failed

Ein Blick in /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log zeigte folgende detailliertere Fehlermeldung:

...
:info:configure checking for static SSL support... disabled
:info:configure checking for SSL support... enabled
:info:configure checking for SSL include directory... Not found
:info:configure 
:info:configure Couldn't find your SSL header files.
:info:configure Use --with-ssl-incl-dir option to fix this problem or disable
:info:configure the SSL support with --without-ssl
:info:configure 
:info:configure Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1" && ./configure --prefix=/opt/local 
:info:configure Exit code: 1
:error:configure Failed to configure monit, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1/config.log
:error:configure org.macports.configure for port monit returned: configure failure: command execution failed
:debug:configure Error code: NONE
:debug:configure Backtrace: configure failure: command execution failed
   while executing
"portconfigure::configure_main org.macports.configure"
   ("eval" body line 1)
   invoked from within
"eval $procedure $targetname"
:info:configure Warning: targets not executed for monit: org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install
:notice:configure Please see the log file for port monit for details:
   /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log

Der relevante Teil des Logs:

...
:info:configure Couldn't find your SSL header files.
:info:configure Use --with-ssl-incl-dir option to fix this problem or disable
:info:configure the SSL support with --without-ssl
...

MacPorts openssl war aber installiert und die Header-Files fanden sich im Pfad /opt/local/include/openssl. Den Pfad hatte ich mit einer Suche nach ssl.h ausgemacht.

Nach mehr als einer Stunde Google-Suche war ich immer noch nicht weiter. Da kam mir der Geistesblitz: Das configure-Script von monit wird die SSL-Headers wohl im Standardverzeichnis suchen. Offenbar gibt es dieses Verzeichnis nicht, weshalb die Installation scheitert … wenn ich aber herausfinde, wie das Standardverzeichnis lautet, kann ich dieses mit einem Symlink auf das MacPorts-Verzeichnis umbiegen und die Installation sollte durchlaufen.

Gesagt, getan. Als erstes startete ich in einem Terminal-Fenster die Installation von monit:

$ sudo port install monit

In einem zweiten Tab führte ich dann folgenden Befehl aus, um alle Zugriffe auf das Dateisystem zu loggen:

$ sudo fs_usage

Nachdem das Tab mit dem MacPorts-Befehl wieder „bash“ als Titel anzeigte, stoppte ich fs_usage mit Ctrl-C. Anschliessend kopierte ich den ganzen Text in eine Textdatei, speicherte diese auf dem Desktop ab und begann, den Text zu greppen.

Ganz am Schluss der Aktivitäten kam heraus:

...
18:17:53  stat64            /usr/include/sys/_pthread/_pthread_key_t.h                                 0.000008   clang       
18:17:53  stat64            /usr/include/sys/_types/_fsblkcnt_t.h                                      0.000008   clang       
18:17:53  stat64            /usr/include/sys/_types/_fsfilcnt_t.h                                      0.000008   clang       
18:17:53  stat64            /opt/local/include                                                         0.000013   clang       
18:17:53  stat64            /usr/local/include                                                         0.000005   clang       
18:17:53  stat64            /usr/local/include                                                         0.000004   clang       
18:17:53  stat64            /Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include    0.000013   clang       
18:17:53  stat64            .app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include    0.000007   clang       
18:17:53  stat64            /usr/include                                                               0.000005   clang

/usr/local/include tönte vielversprechend nach einem Standardpfad … und Bingo:

$ cd /usr/local/include
-bash: /usr/local/include: No such file or directory

Tönt wie ein Volltreffer. Dann versuchen wir es doch einmal damit:

$ sudo mkdir /usr/local/include
$ cd /usr/local/include
$ sudo ln -s /opt/local/include/openssl .

Alles bereit für den Versuch? Dann los — et voilà:

$ sudo port install monit
--->  Computing dependencies for monit
--->  Configuring monit
--->  Building monit
--->  Staging monit into destroot
--->  Creating launchd control script
###########################################################
# A startup item has been generated that will aid in
# starting monit with launchd. It is disabled
# by default. Execute the following command to start it,
# and to cause it to launch at startup:
#
# sudo port load monit
###########################################################
--->  Installing monit @5.12.1_1
--->  Activating monit @5.12.1_1
--->  Cleaning monit
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.

Die Jungs von homebrew haben die Problematik übrigens direkt im config-File gefixt, und zwar mit dem Parameter --with-ssl-dir, welches auf den openssl-Pfad zeigt:

...
def install
    system "./configure", "--prefix=#{prefix}",
                          "--localstatedir=#{var}/monit",
                          "--sysconfdir=#{etc}/monit",
                          "--with-ssl-dir=#{Formula["openssl"].opt_prefix}"
    system "make", "install"
    (share/"monit").install "monitrc"
...

Quelle: homebrew/monit.rb at master

Tags: , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 16. Oktober 2012

Aus einer S/MIME verschlüsselten E-Mail-Nachricht das DER-Zertifikat des Senders extrahieren

Damit man Lotus Notes zur verschlüsselten S/MIME-Kommunikation mit anderen Internetbenutzern bewegen kann, sind einige Kapriolen nötig (ich habe bereits darüber gebloggt).

Heute hatte ich einen neuen Fall: Ein Kunde schickte auf ein von mir signiertes S/MIME-Mail eine S/MIME-verschlüsselte Antwort zurück. Lotus Notes entschlüsselte den Text brav im Hintergrund (ich habe mein VeriSign-Zertifikat im Mail-Client hinterlegt), doch wie immer landete trotz der abgenickten „Cross Certify“–Abfrage kein Zertifikat in meinem lokalen Adressbuchkontakt des Ansprechpartners. Ein mir bekanntes Problem, welches verhindert, dass ich der Person ebenfalls verschlüsselt antworten kann.

Wie nicht anders zu erwarten war, habe ich es irgendwann einmal dann doch noch geschafft, aus dieser Nachricht das X.509-Zertifikat des Ansprechpartners zu extrahieren. Rückblickend sieht es — unter uns gesagt — gar nicht so kompliziert aus:

Verschlüsselten Textblock ins Dateisystem abspeichern

Hierzu öffnet man die Nachricht zuerst einmal mit Doppelklick. Dann klickt man in den Body der Nachricht. Danach:

  1. View
  2. Show
  3. Page Source

Man selektiert den ganzen Text ab hier …

Content-Transfer-Encoding: base64
Content-class: urn:content-classes:message
Content-Type: application/x-pkcs7-mime;
		 name="smime.p7m"
Content-Disposition: attachment;
		 filename="smime.p7m"
Content-Description: smime.p7m

MIImFQYJ ...

… gefolgt vom Base64-enkodierten verschlüsselten Text.

Den Zeichensalat kopiert man in eine Textdatei, die man bspw. encrypted.p7m nennt.

openssl für Windows

Als nächstes besorgt man sich die Win32-Binaries von OpenSSL:

Win32 OpenSSL

Diese werden wie vorgeschlagen unter C:\OpenSSL-Win32 installiert. Dabei kann es nicht schaden, den Pfad auch gleich noch in die PATH-Variable des Environments aufzunehmen:

  1. System Properties
  2. Advanced
  3. Environment Variables
  4. User variables for %USER%
  5. PATH
  6. Edit

Eigenes Zertifikat verfügbar machen

Um eine Textdatei mit OpenSSL zu entschlüsseln, benötigt man selbstverständlich noch seinen eigenen privaten Schlüssel. Diesen habe ich als .pfx aus dem Microsoft Certificate Manager extrahiert und im Dateisystem abgelegt. Wichtig ist, dass man den Private Key explizit auch exportiert, sonst bringt die ganze Übung nichts.

Damit OpenSSL das Zertifikat versteht, muss es von PFX nach PEM umgewandelt werden:

openssl pkcs12 -in mario-aeby.pfx -out mario-aeby.pem -nodes

Quelle: How to Convert PFX Certificate to PEM Format for Use with Citrix Access Gateway

Wer sein Import Password vergessen hat … muss hier leider aufhören. Wer sich aber an das Passwort erinnern kann und es openssl übergibt, liest umgehend:

MAC verified OK

Schaut man sich die .pem-Datei an, liest man in meinem spezifischen Fall folgendes:

Bag Attributes
   localKeyID: 01 00 00 00
   friendlyName: le-f2f17a0f-253d-4395-a852-137b4c1ad697
   Microsoft CSP Name: Microsoft Strong Cryptographic Provider
Key Attributes
   X509v3 Key Usage: 10
-----BEGIN PRIVATE KEY-----
MII...

Ordnerinhalt

Der Ordner sollte nun enthalten:

  • smime.p7m
  • mario-aeby.pfx
  • mario-aeby.pem

Entschlüsseln

Nun geht es ans Eingemachte:

openssl smime -decrypt -in encrypted.p7m -inform SMIME -inkey mario-aeby.pem -out decrypted.p7m -outform SMIME

Wird von OpenSSL keine Fehlermeldung ausgegeben, konnte die Nachricht entschlüsselt werden. Die Nachricht liegt ebenfalls als Base64-kodierter Zeichenhaufen in der Datei decrypted.p7m

Zertifikat des Senders extrahieren

Nun kann man das Zertifikat des Senders aus der unverschlüsselten, aber signierten Nachricht extrahieren:

openssl smime -verify -noverify -in decrypted.p7m -signer sender.pem

Informationen über das Zertifikat

Wenn wir uns die sender.pem anschauen, finden wir heraus, wo der Absender sein Zertifikat gelöst hat (in dem vorliegenden Fall war es SwissSign):

openssl x509 -in sender.pem -text

Umwandlung in ein DER-Zertifikat

Fast haben wir es geschafft. Mit folgendem Befehl produzieren wir ein DER-Zertifikat, welches Lotus Notes versteht und in das Adressbuch importieren kann:

openssl x509 -in sender.pem -outform der -out sender.der

Import in Lotus Notes

Hierzu öffnet man das Adressbuch und öffnet die Adresskarte des Senders mittels Doppelklick. Anschliessend importiert man das Zertifikat:

  1. Actions
  2. Certificates
  3. Import Internet Certificates
  4. Files of type: Binary and Base64 Files (*.cer, *.der)
  5. <Auswahl der Datei sender.der im Dateisystem>
  6. Open

Fertig!

Links

Nebenbemerkung

Zertifikatanbieter wie bspw. QuoVadis Trustlink Schweiz AG bieten auf Ihren Homepages die Möglichkeit an, nach Angabe der E-Mail-Adresse des Zertifikatbesitzers dessen Public Key herunterzuladen.

Bei SwissSign fand ich — nur per Zufall und langem Suchen — folgendes Abfrageformular:

Search / Manage

Die E-Mail-Adresse des Ansprechpartners fand sich aber nicht in der Datenbank. Ansonsten hätte ich von hier den Public Key respektive das DER-Zertifikat herunterladen können.

Tags: , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 15. Juni 2008

Wie zwei auskommentierte Zeilen Code SSL-Zertifikate unbrauchbar machten

/* MD_Update(&m,buf,j); */

Quelle: Diff for /openssl/trunk/rand/md_rand.c between version 140 and 141

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen