Re: [Fed-Talk] CAC Setup on Intel MACs (additional step)
Re: [Fed-Talk] CAC Setup on Intel MACs (additional step)
- Subject: Re: [Fed-Talk] CAC Setup on Intel MACs (additional step)
- From: "Shawn A. Geddis" <email@hidden>
- Date: Wed, 10 Oct 2007 18:41:26 -0400
On Oct 8, 2007, at 1:59 PM, Robert Gottlieb wrote:
Shawn,
If I want to be compatible with the new way going forward, what are
the steps to get Firefox working? I can get Safari working no
problem.
In particular, when I try to load a ges portal page it gives me an
error saying that there is a problem with my certificate database
error -8174.
In any case, I want to do whatever is most compatible with Leopard
as that is what I will be running as soon as it is released.
Thanks,
Robert Gottlieb
email@hidden
Robert,
As noted on other threads, Firefox is PKCS#11 based and is not
integrated with Mac OS X 10.4.0 and beyond. That said, there is
nothing you can do as a user, unfortunately, to configure FireFox to
leverage the built-in Smart Card Services.
I will try to keep the following simplified enough that most everyone
on this list will understand and convey some meaningful info...
One outstanding Issue faced with accessing some DoD services is that
two Certificates (ID & Email Signing) issued on the CAC have the same
Key Usage and are valid for those services (i.e. SSL/TLS and VPN).
The vast majority of servers within DoD are enforcing the use of the
"Email Signing Cert" for user Authentication. In an effort to provide
a "zero-config" like environment on Mac OS X, the OS will
automatically select the first *valid* Cert for the required usage (in
this case the ID Cert) and send that as part of the User
Authentication process. I am not personally aware of any DoD service
that utilizes the ID Cert in any form (I am sure someone has one up),
but they all seem to overload the use of the Email Signing Cert.
There are folks on this list that can explain in detail why that was
the chosen method within DoD.
Some Servers, unfortunately, do not fail the handshake at the protocol
level (i.e. SSL negotiation), but rather return an HTML Web page
indicating that the user needs to select the right certificate (this
is a Windows approach to solving this problem). If the service failed
at the protocol level, Mac OS X would notify Safari which would
acknowledge this to the user and present the user with an Identity
selection sheet -- showing all of the additional valid certificates to
choose from. This is where the user would be able to select an
alternative certificate. Once one is selected, an Identity Preference
is added to the user's Keychain and from that point on, the selected
identity is automatically used when negotiating access to that
particular URL.
When servers do not fail at the protocol level, it causes a catch-22
situation and the user is caught in the middle. The simplest and
arguably the best approach is to correct the servers, but most admins
will not change things on the server side since that is the scenario
which works for Windows clients. I have provided a "non-supported"
Identity Preference Setting Tool to allow users to set the Identity
Preference I spoke of earlier. With this, they are able to manually
setup an Identity Preference with the URL and selection of the desired
Certificate -- before attempting to connect to the server. I realize
some of you have been utilizing tools from others to "address this
issue". Use those tools at your own risk, since any approach other
than the creation of an appropriate Identity Preference stored in the
user's keychain may result in unexpected behavior. The ability to
create and manage Identity Preferences to address this catch-22
frustration with DoD services will be available in Keychain Access
(contextual menu item) coming in Leopard - Mac OS X 10.5.
The core difference to keep in mind here is that under Mac OS X, the
processing (parsing, validation, etc.) of X.509 credentials is done by
the OS where many agree that it should be and not enforced by
applications. Also, the setting of Key Usage on Certificates is
critical to proper handling within a PKI as you can see.
A point of Irony:
As of a year ago, staff coming out of DoD Schools were being issued a
CAC with ONLY an ID Cert. As such, they were unable to even login on
their Windows machines because it lacked an "Email Signing Cert" which
was required for login with a CAC under Windows. This is one time
when you would logically think that an ID Cert would be used.
- Shawn
_____________________________________________________
Shawn Geddis Security Consulting Engineer Apple Enterprise
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