Diff Encryption Certificates used by diff users in same AD domain.

[Jonathan Forbes]

Hello,

I'm working in a native 2003 AD domain. We sign and encrypt email to and
from both inter and intra-domain users. We recieve our certificates from
third party CA. These certificates have a finite time of validity and
eventually need to be renewed.

We have renewed a particular users certs in the accepted fashion; cleaned
old certs by publishing blank to GAL within outlook, created new security
settings with new certs and republished to GAL. The newly published cert has
been confirmed in AD using AD Users/Computers snap-in, as well as ADSIEdit
snap-in.

At this time only one interdomain user is able to encrypt a message to the
newly cert-ed user. 3 other interdomain users (myself included) send
encrypted messages to the user, but the user cannot open them (the ubiquitos
Cannot open this item. Your Digital ID...etc)

We have a CRL program (Tumbleweed) shimmed between Outlook and Microsoft
CAPI. as well as a Smart Card middleware program (ActivClient) handling
certs. Tumbleweed logs CRL checking for any certificate activity. When I send
an encrypted message to the user in question, the event log for Tumbleweed
fires a success audit for the certificate used to encrypt the message. The
problem is it's clearly the wrong certificate (the cert that was cleaned from
AD and deleted from my contacts list). This explains why the user cannot open
encrypted messages from me. The user can open encrypted mail from only one
intra-domain user so far; and that users Tumbleweed log shows the correct
cert being used.

I'm aware of 3 places Outlook obtains encryption certs from: AD attribute
userS/MIMECertificate...the clients contact list...and OAB. I believe I've
cleaned all these of the old cert yet my Outlook client continues to use it,
and the Outlook client of at least one user is using the new one.

Since it seems client-centric, what must be done on an Outlook client to
definitively ensure that only one (the newest) cert is used for each AD user
object?

 

[Brian Tillman]

I'm working in a native 2003 AD domain. We sign and encrypt email to
and from both inter and intra-domain users. We recieve our
certificates from third party CA. These certificates have a finite
time of validity and eventually need to be renewed.

We have renewed a particular users certs in the accepted fashion;
cleaned old certs by publishing blank to GAL within outlook, created
new security settings with new certs and republished to GAL. The
newly published cert has been confirmed in AD using AD
Users/Computers snap-in, as well as ADSIEdit snap-in.

At this time only one interdomain user is able to encrypt a message
to the newly cert-ed user. 3 other interdomain users (myself
included) send encrypted messages to the user, but the user cannot
open them (the ubiquitos Cannot open this item. Your Digital ID...etc)

You should never delete expired certificates. That will remove the ability
of the person to open received messages encrypted when that certificate was
current.

Try removing the person's old certificate from the Other People store. You
can do this from either Internet Explorer (the Content tab of IE's
Tools>Internet Options) or by running certmgr.msc from Start>Run. This
should cause Outlook to reload the current cert from AD when you select him
from the GAL.

 

[Jonathan Forbes]

Brian, thank you for your response.

My local store had the current certificates listed. I removed them anyway,
suspecting the missing cert would prompt Outlook to query AD for it. I sent a
test email to the user in question. The CRL software confirmed that the old
cert was still used to encrypt the message.

What about the .nk2 auto complete cache? Does it cache more than just
addresses? It would appear that in spite of deleting the old certs, my local
system is still using it from somewhere. Thanks.

 

[Brian Tillman]

My local store had the current certificates listed. I removed them
anyway, suspecting the missing cert would prompt Outlook to query AD
for it. I sent a test email to the user in question. The CRL software
confirmed that the old cert was still used to encrypt the message.

Is that person in your Contacts folder as well as the GAL? If so, try
deleting the contact record from your Contacts folder.

What about the .nk2 auto complete cache? Does it cache more than just
addresses? It would appear that in spite of deleting the old certs,
my local system is still using it from somewhere. Thanks.

Beats me, but it sure can't hurt to delete the name from the cache and try
again.

 

[Jonathan Forbes]

I had removed her from my Contacts folder during initial troubleshooting.
Then added her back (confirming that her latest certificate was there) and
Outlook still got her old cert from somewhere. Then I deleted her from my
Contacts and got the same result.

I also deleted her name from the auto complete cache as well. Same result.

I have also tested this with one of the other users who has the same
problem, with the same result. It is certainly application/client-centric
(some clients have it, so far one client doesn't) Is there a way to debug, or
log Outlooks certificate handling process? Or definitively identify Outlooks
sources for certificates, and then eliminate each one until something
different happens?

Thank you again.

 

[Jonathan Forbes]

I've resolved the issue, but in doing so uncovered another issue.

I learned that in Cached Exchange Mode, Outlook does not query AD for
addresses; but instead looks to the OAB...regardless of whether Outlook is
online or not, it seems. This condition would suggest that in cached mode,
the OAB is not updated, or our OAB is not being updated in general.

Once I cleared the Cached Exchange Mode checkbox in Exchange Server
settings, Outlook picked up the correct cert from AD and the message was
encrypted and decrypted successfully.

Thanks for your help!

 

[Brian Tillman]

I've resolved the issue, but in doing so uncovered another issue.

I learned that in Cached Exchange Mode, Outlook does not query AD for
addresses; but instead looks to the OAB...

Duh. I should have thought of that.

Delete the OST and OAB and let Outlook recreate them.