Hello,

I'm not quite sure what led to adding this line to the recent version of library (method byte[] GetSerialNumber(), file Certificate.cs):

Array.Reverse(ret);

This breaks the compatibility with older versions of library, and also with Microsoft's WSE.

We use certificate serial number for identifying the certificate in our project (what is probably not the best way, since two certificates from different CAs could easily have same SN).

An off-topic question, but I hope nobody would mind if I ask it, what is the "correct" or standard way of identifying the certificate (which was used for signing/encrypting)? Hash code?

Marian

> This breaks the compatibility with older versions
> of library, and also with Microsoft's WSE.

It's a bug in the .NET framework v1.0/1.1, the WSE library and our older SecLib versions. The Windows CryptoAPI uses little endian byte ordening and .NET uses big endian, so the serial number had to be reversed (something we and Microsoft initially missed). If you open the certificate in internet explorer, you'll see that IE correctly shows the serial number in its big endian form.

This bug will be fixed in .NET 2.0 and it's already fixed in our SecLib.

> An off-topic question, but I hope nobody would mind
> if I ask it, what is the "correct" or standard way
> of identifying the certificate (which was used for
> signing/encrypting)? Hash code?

The safest way to identify a certificate is by using its hash value (be careful not to mistake the hash value with the hash cod; GetHashCode is a method inherited from the Object class and cannot be used to identify a certificate).
You can get the hash value of a certificate by calling the GetCertHash method or GetCertHashString method.