Hi all,

The other day a customer of mine was trying to use OWA to sign an email with a specific certificate, with no success.

To put you in situation, he had two certificates with very similar properties, but slightly different. When he accessed OWA, the mime control picked up the wrong cert, instead of giving them the option to choose between the valid certs in his Personal store.

We debugged the issue and saw that this is by design in OWA: it calls CryptoAPI and goes through the list of available certs until it finds the one that matches certain conditions (valid email address and usage), and uses that one. It doesn't care if there are more valid certs in the list.

So this customer asked us how CryptoAPI orders the certs in the Personal/MY store, in case he could change some property when issuing the certs so they were ordered in a way that the first valid cert that OWA gets is the one he needs.

This is what I found when I debugged the CryptoAPI calls that OWA makes behind the scenes (Disclaimer: The following info is not documented so it may change at any time without warning):

We call CertOpenStore to access the Personal/MY certificate store. There we create an internal list with all available certs. To create that list we go through the available certs by thumbprint (normally a SHA1 hash of the cert). This is an example of the order on which we will read the certs:

0046EA83C83F13336353423F4ED54DA2D118D8AD
19D00F25CAA644C3C41D46BF628EB62B3539BC87 (The one we want OWA to use)
C08025194F09B03C16AB87EA2BCD5D31DBE7738F (The one OWA uses)

In the list we create, the first element of the list is the last one that gets inserted. So the list for the above certs will look like this:

C08025194F09B03C16AB87EA2BCD5D31DBE7738F --> 19D00F25CAA644C3C41D46BF628EB62B3539BC87 --> 0046EA83C83F13336353423F4ED54DA2D118D8AD

Now, when we go through it with CertEnumCertificatesInStore, the first cert we get is C08025194F09B03C16AB87EA2BCD5D31DBE7738F. The properties of this cert match what OWA expects, so OWA won't keep looking and we won't get to the next cert in the list, 19D00F25CAA644C3C41D46BF628EB62B3539BC87, the one we wanted to use.

If we are lucky, the cert we want will be the first one on the list. But there is no way for us to affect this behavior by e.g. changing the properties of the cert, as we have no idea which hash will get generated for our cert.

Regards,

Alex (Alejandro Campos Magencio)