Re: [Fed-Talk] X.509 Certificates, Apple Mail, Key Chain
Re: [Fed-Talk] X.509 Certificates, Apple Mail, Key Chain
- Subject: Re: [Fed-Talk] X.509 Certificates, Apple Mail, Key Chain
- From: "Timothy J. Miller" <email@hidden>
- Date: Thu, 2 Aug 2007 09:56:37 -0500
On Aug 2, 2007, at 9:23 AM, Paul Derby wrote:
How does all this work from the User perspective? Is there a good
end user oriented document we could hand out to get people started?
Not really, at least, not that I've seen. Primarily it "just
works"(TM).
As X.509 certificates expire, it would seem that you need to leave
them in your key chain so you can go back and read old emails that
are encrypted. Does Apple Mail and OS X work to pick the "right"
certificate as encrypted mail builds up over the years?
Yes. :)
Sometimes you need to move your certificate from the Keychain into
a Windows XP environment. Does anyone know a successful way to do
this? So if you have Windows XP running on your Mac under
Parallels and you have installed a certificate from Thawte, how do
you export the certificate from your Keychain in a format that is
importable into Windows XP? We can generate certificates in XP and
Outlook works just fine, but we haven't been able to move a
certificate from OS X into Windows for users that use both OS X and
Parallels/WIndows XP on the same MacBook Pro machines.
Select the cert and the corresponding private key and do a File |
Export as a PKCS#12 file (.pfx or .p12 extension). Windows will
import these with no trouble when you double-click on them.
Where is the certificate store for Windows XP? Is there something
like Keychain where you can go look to see what certificates you
have and view their characteristics?
They're in the registry, mostly. It's possible to have keys
elsewhere, but the registry is the default.
Run MMC and add a Certificates snap-in for the current user. The
"Personal" store will have your personal certificates, the "Trusted
Roots" store has the root CA certs, and the intermediates has the sub-
CAs--though you can put sub-CAs in the root store with no ill effects.
Also, are other people having problems sending encrypted email to
US Army email addresses where the receiver authenticates with their
CAC card and uses their CAC card for decryption. It seems the Army
is encoding the user's exchange server email address on the CAC
card, not their AKO email address. Many folks in the Army use
their AKO email address and forward that to their exchange email
address. Since the AKO email address isn't on the CAC card the
receiver can't decrypt their email. Any thoughts on how to deal
with this situation?
Receivers are always be able to decrypt encrypted messages if they
have the right private key. I explicitly tested this case in a eight
different S/MIME MUAs and all of them--including Outlook and Apple
Mail--passed that test.
However, the *sender* may not be able to encrypt a message to a
recipient if the email address in the recipient's cert doesn't match
the address you're sending to. This is a strict interpretation of
the RFC, and is common to most S/MIME MUAs, including Apple Mail. Of
all the MUAs I tested, only Outlook could have this behavior changed
(via the SupressNameChecks registry setting).
However, Army should (soon) start using the AKO address in email
certificates. AF is ramping up to do the same with the Email-4-Life
effort. This will solve the problem without requiring MUAs to
violate the letter of the RFC.
In the interim the only reliable way to make this work is Outlook
with SupressNameChecks turned on.
-- Tim
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden