Claws Mail & S/MIME plugin howto
Recently there were many requests on the mailing list on how to configure the S/MIME plugin to work properly. It is not a trivial task as the GUI doesn't provide any configuration options and everything needs to be done in the console.
I've had a "half-working" setup but always failed on some point when importing S/MIME certificates. I now managed to have a working config and hopefully this howto will give an insight on how to achieve it.
This howto is based on Gentoo but should be working fine on every other distribution if adjusting it accordingly :)
- recent Claws Mail version, recommended: v2.7.1 (multiple RFC fixes), or CVS
- recent S/MIME plugin, recommended: v0.6.0 (multiple RFC fixes), or CVS
- S/MIME certificate (this howto is based on Thawte Freemail certs)
- pinentry, gnupg, gpgme, ca-certificates (and openssl) in recent versions
- gpg-agent to cache the passphrase
Those are the versions I'm using:
# emerge -p pinentry gnupg gpgme ca-certificates [ebuild R ] app-crypt/pinentry-0.7.2-r3 USE="gtk ncurses qt3 -caps" 390 kB [ebuild R ] app-crypt/gnupg-2.0.1-r1 USE="X bzip2 ldap nls -caps -doc -openct -pcsc-lite (-selinux) -smartcard" 0 kB [ebuild R ] app-crypt/gpgme-1.1.2-r1 0 kB [ebuild R ] app-misc/ca-certificates-20050804 92 kB
I'm using keychain to start gpg-agent. Choose what you like, here are somes howtos:
Runing the GPG agent
If you're using gpg2, then because of gpgme, claws-mail will depend on a running gpg-agent. This means, you will have to run a gpg-agent in order to be able to use anything via gpgme. A gpg-agent will need a pinentry application to ask for the pin. Running gpg-agent is quite trivial:
eval `gpg-agent --daemon`
As you see, it eval's, that means, gpg-agent returns an environment variable and exports it, something like `FOO=bar; export FOO`. This means, that you will have to run claws-mail from the same session, because it will need this environment variable in order to access the agent. check gpg-agent(1) for more details on the usual startup customs.
KDE has a way to run scripts and thus export environment variables at startup time. Every application running in this session will get these variables, so it's very handsome here. All you have to do is create a file under ~/.kde/env/ (if it doesn't exist, then create it). I named it gpgagent.sh. The contents of this shell script is quite trivial:
#!/bin/sh eval `gpg-agent --daemon`
Importing S/MIME certificates into gpgsm
First one has to obtain the Thawte Freemail certificate and install it into Firefox/Thunderbird. Export/Backup the certificate from Firefox/Thunderbird e.g. to "certbundle.p12" file and remember the passphrase.
Convert the file into PEM format:
$ openssl pkcs12 -in certbundle.p12 -out certbundle.pem -nodes
(use the export passphrase)
Extract the key:
$ openssl pkcs12 -in certbundle.pem -export -out certkey.p12 -nocerts -nodes
Import the key into gpgsm:
$ gpgsm --call-protect-tool --p12-import --store certkey.p12
Now one has to add the issuers certificate (Thawte) into gpgsm, you can use the certs included in the Freemail cert, but I did the following:
$ gpgsm --import /usr/share/ca-certificates/mozilla/Thawte*
(Thawte_Personal_Basic_CA.crt, Thawte_Personal_Premium_CA.crt, Thawte_Server_CA.crt, Thawte_Personal_Freemail_CA.crt, Thawte_Premium_Server_CA.crt, Thawte_Time_Stamping_CA.crt)
Check if your key has been added:
$ gpgsm --list-secret-keys
If this doesn't show a secret key, you may have to import the three certificates from certbundle.pem: separate them to three files (starting with "--- BEGIN CERTIFICATE ---" and ending with "--- END CERTIFICATE ---"), then run
$ gpgsm --import cert1.pem cert2.pem cert3.pem
You need to create the file (if it doesn't exist) "$HOME/.gnupg/trustlist.txt" to add Thawte to the trusted key list. This makes it possible to verify/sign/.../ with your Thawte certificate. I also added my own certificate to the trustlist. Add the following lines which contain the fingerprint (not serial number!) of the key and the letter S at the end:
# 1.2.840.113518.104.22.168=#706572736F6E616C2D667265656D61696C407468617774652E636F6D,CN=Thawte # Personal Freemail CA,OU=Certification Services Division,O=Thawte # Consulting,L=Cape Town,ST=Western Cape,C=ZA 209900B63D955728140CD13622D8C687A4EB0085 S
You'll enter your own key similarly
This is my "$HOME/.gnupg/gpgsm.conf":
disable-crl-checks disable-policy-checks auto-issuer-key-retrieve debug-level basic
You will also probably want to enter your:
gpg-agent is only necessary for caching the passphrase: "$HOME/.gnupg/gpg-agent.conf"
pinentry-program /usr/bin/pinentry-qt default-cache-ttl 86400 # be aware that the passphrases will be cached for 86400 seconds! set accordingly to your need max-cache-ttl 86400 disable-scdaemon allow-mark-trusted
Working with S/MIME plugin and problems/bugs
- As of current CVS (CM =>2.7.0cvs11 and S/MIME >=0.5.8cvs2) the S/MIME plugin is more RFC compliant and signing, encrypting, decrypting and verifying messages is working very well now. I tested compatibility with Outlook 11 and Thunderbird, some Kmail emails in my inbox decrypt fine too!
- I'm only aware of one problem, where you'll get "Bad signature" warnings, when you forward (via CM) a signed+encrypted email with an attachment and sign+encrypt the email itself again too.
- Error: Couldn't decrypt: "unsupported algorithm" - this happens when you receive an email which got encrypted with RC2 algorithm (e.g. some Outlook 11 and some Thunderbird MUAs). I'm currently not aware of a solution, as the underlying libgcrypt doesn't handle it for patent reasons. (see https://intevation.de/roundup/aegypten/issue11 and http://forums.mozillazine.org/viewtopic.php?p=2858116 )
- It seems the "Trust key" dialog doesn't show the name of the key, e.g. "The key of ' ' is not fully trusted".
CM first asks for the key of the recipient and then asks for the sender's key because CM can't extract it properly: "No exact match for 'email@address'; please select the key." (guess that is because I have two certs..).
If I send an email to a friend and include myself (To:), CM will ask me three times for the correct keys.
- As of now the "Select Keys" dialog when encrypting emails is a bit awkward to use if you have more than one key (e.g. one additional key that is expired and you still want to keep it to be able to decrypt older emails). It only shows the Key ID and no info about the expiry date which makes it more difficult to choose the correct one.