I had an interesting question posed ot me today by Dominic who asked me to verify whether his all new Digital certificate was correctly being used for signing mail. Thunderbird sadly complained that the signature was invalid, which was unexpected, and that the issuer was unknown ( expected since it comes form a private hierarchy.) The question then lead to where did the problem lie?
My gut feel was that it was the disclaimer being inserted by an intermediary gateway ( one has to love corpmail). Setting about proving this was the hard part. The first issue at hand wa to actually extract the certificates so I could play with the verification. Cert Viewer Plus for Thunderbird made this part a dream. Creating a modified version of the signed message was a little bit more problematic.
Trusting the command line, I started hunting around for details on openssl support for SMIME, which it has. OPenSSL needs a full CA path for being able to verify SMIME signed messages. One can optain this from various places ( such as exporting form your browser) but in a case like this where a private hierarchy was being used, its enough to just make used of a somewhat smaller subset contianing only the certificates used in this chain. These can be extracted using Cert Viewer Plus. Alternately some command line magic can be used to extract the PKCS7 formatted embedded certificates out in standard PEM format., using the following command:
openssl smime -pk7out -in mail.txt | \
openssl pkcs7 -print_certs > extract.crt
Now that we have a certificate chain we can attempt the verify. The extract.crt below can be either from the openssl method above or the Cert Viewer plus PEM dump.
openssl smime -CAfile extract.crt -verify -in mail.txt
Now e actually have a more usable error message. Although I really don’t know why I have such a deep distrust in GUI apps for actually telling me what is wrong.
Verification failure
88175:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/pkcs7/pk7_doit.c:808:
88175:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/pkcs7/pk7_smime.c:265:
As suspected the digest filed, which lead to a overall signature failure. The next step was to see if removing the disclaimer worked. Repeating on a slightly edited version of the the mail gave the following:
openssl smime -CAfile extract.crt -verify -in mail2.txt
...
mail contents deleted
...
Verification successful
So the original question posed was if the signature system was working correctly which it now was. The differences between the two mail files was checked using diff
diff -u mail.txt mail2.txt
--- mail.txt Mon Aug 25 18:06:33 2008
+++ mail2.txt Mon Aug 25 18:08:10 2008
@@ -61,10 +61,6 @@
South Africa
-Important Notice: This email is subject to important restrictions, qualifications
and disclaimers ("the Disclaimer") ..that all was one very long line that made
up the corporate disclaimer.....
-
-
-
------=_NextPart_000_0048_01C906C7.DB6FB700
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
From the above the only difference shown is that a mailgateway had added in a extra four lines of disclaimer and whitespace padding. The question now evolves as to how to provide the now pretty much ubiquitious organisational disclaimer in outgoing mail in such a way that it doesnt trash any cryptographic operations in which the mail is involved. Ive gone back over mails from a couple of other people in corporate South Africa that I know , and the problem seems to be widespread.
The solution may be that the disclaimer as such is encapsulated as a separeate mime component, which is what interestingly one university here does ( although it insists on prepending its mime encapsulated HTML disclaimer, which makes for relaly ugly mail reading!)
