EldoS | Feel safer!

Software components for data protection, secure storage and transfer

SignerCertificate missing

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
Posted: 05/11/2010 07:41:26
by  Flemming Hansen

Im trying to Decrypt a signed/encrypted SMIME email sent to me from a customer.

For some reason the SBSMIMECore.TElMessagePartHandlerSMime.DecoderSignCertStorage field is null, but the
filed DecoderSignIsCorrectly = true. (After calling MainPart.MessagePartHandler.Decode(true))

This should indicate that the message is signed but why cant I get access to the signer certificate?

This error have been reproduced in the SecureMail_VS2008 sample application.

The really weird part of this, is that my code and SecureMail give an returncode (from Decode(true)) = 1 (Warning)
and the ErrorText = "Cannot check S/MIME Message. Message was corrupted"
on the MainPart.MessagePartHandler.
Despite of this the SBSMIMECore.TElMessagePartHandlerSMime.DecoderSignIsCorrectly = true

If the DecoderSignIsCorrectly = true, why arent the DecoderSignCertStorage filled with the signercertificate?

I have attached a zip file with 2 test emails and a certificate to decrypt the emails with. (Password in a textfile)


Using version 7.2.168 of SecureBlackBox .Net version C#
Emails are comming though Exchange Server 2007 with the fixes from http://support.microsoft.com/kb/949703

Kind Regard Flemming
Posted: 05/11/2010 08:08:28
by  Flemming Hansen
Another thing i just discovered.

If I set DecoderIncludeIssuerCertificates = false, then I dont get the
ErrorText = "Cannot check S/MIME Message. Message was corrupted" and the
returncode from Decode(true) = 0.

This doesnt change the DecoderSignIsCorrectly and the DecoderSignCertStorage problem.

Kind Regard
Posted: 05/14/2010 03:59:17
by Ken Ivanov (EldoS Corp.)

Thank you for contacting us and sorry for the delayed reply.

Unfortunately, there is no ZIP file attached to your message. Could you please try to re-post it?
Posted: 05/14/2010 06:04:49
by  Flemming Hansen
Hmm, yes sorry..

Here it is..

[ Download ]
Posted: 05/17/2010 14:49:39
by Ken Ivanov (EldoS Corp.)

Thank you for the files.

The messages really contain invalid signatures -- probably right due to the Microsoft Exchange problem described in the article you have mentioned in your very first message. It is likely that the server has changed or added some headers to the message, invalidating it.

We are now trying to reproduce the symptoms you reported (we always get error code 9 along with smeInvalidSignature error message). Could you please describe the exact steps you are performing with the Secure Mail sample?
Posted: 05/18/2010 02:18:39
by  Flemming Hansen
Hi Ivanov

When im running the Secure Mail Sample (VS 2008 version)

I run the sample from within VS 2008, in Debug mode.

1) Choose Decrypt Message, Next
2) Choose one of the test files, eg. SEPO 8-43.txt, write filename in outpu file, Next
3) Choose "Digital Signatur Indgaende.pfx", input password, Next
4) Click on Decrypt
5) Have breakpoint in codefile: SecureMailWin.cs line 2084
SBSMIMECore.TElMessagePartHandlerSMime SMime = (SBSMIMECore.TElMessagePartHandlerSMime)Msg.MainPart.MessagePartHandler;

When i inspect SMime variable here, the DecoderSignIsCorrectly and the DecoderSignCertStorage are offcourse empty.

6) Debug until line 2089:
Res = Msg.MainPart.MessagePartHandler.Decode(true);

After this line, i expect SMime to have DecoderSignCertStorage filled, but its empty.

The rest of the code runs normally, and the message gets extracted properly.
My problem is that i need the signercertificate.

Regarding the Exchange Server problem, im investigating now if our exchange admins really have implemented the fix, like they say they have.
Posted: 05/20/2010 14:27:01
by Eugene Mayevski (EldoS Corp.)

JFYI: We are still working on the problem (it's more conceptual, than technical). I hope to have a solution during tomorrow.
Posted: 05/21/2010 07:24:56
by Eugene Mayevski (EldoS Corp.)

I have analyzed your problem carefully and came to conclusion, that there's no problem here, but a misunderstanding.

What you have is a message A, which is signed to get message B. Message B is encrypted to get message C. When you decrypt message C, you are working with part handler SMime. But this part handler is responsible for decryption only(!), not for signature verification. When you call SMime.Decode(true), you tell the part handler to decrypt the data and IF the data includes any parts inside (which it does in message B), *create* new part handlers (inside) and let them process message B. So *another* part handler (say SMime2) is created to process message B and get message A. Next, message A substitutes message B in the MIME tree, however, SMime2 is deleted. In other words, you are checking the part handler which is not related to verification if signature of message B. Because SMIME belongs to message A.

Solution is simple - call Decode(false), then you get message B. Then process message B as if it were a regular message. This way you get access to SMime2 and it's properties.

You would ask "why not just copy the properties of SMime2 to SMime". We can't because SMime2 and SMime are not related. While in your particular case they are of the same type (SMIME), you can have anything instead of SMime2 inside (for example, PGP/MIME-signed message).

Sincerely yours
Eugene Mayevski
Posted: 06/01/2010 03:36:44
by  Flemming Hansen
Hi Eugene

Thanks for the explanation.

I have modified my code so I now will try to do it this way if I dont get the signercertificate in the first try.

I had only tested the code with emails from outlook and from SecureBlackBox before this, and they seem to sign and encrypt in one operation.

Kind Regard
Posted: 06/01/2010 03:55:09
by Eugene Mayevski (EldoS Corp.)

While they can do this in one operation, from MIME point of view, you have several different entries, which must be treated separately.

Sincerely yours
Eugene Mayevski
Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.



Topic viewed 1629 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!