[Fed-Talk] ActivClient on Leopard
[Fed-Talk] ActivClient on Leopard
- Subject: [Fed-Talk] ActivClient on Leopard
- From: "Ekrem, Bryce D CIV SPAWARSYSCEN, J723" <email@hidden>
- Date: Mon, 9 Mar 2009 07:58:46 -0400
- Thread-topic: ActivClient on Leopard
What version of activclient software do I need to connect a CAC reader to leopard?
Bryce Ekrem
Security+
SPAWAR Systems Center Atlantic
email@hidden
843-218-5894
________________________________
From: fed-talk-bounces+bryce.ekrem=email@hidden on behalf of email@hidden
Sent: Mon 3/9/09 3:10 AM
To: email@hidden
Subject: Fed-talk Digest, Vol 6, Issue 65
Send Fed-talk mailing list submissions to
email@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.apple.com/mailman/listinfo/fed-talk
or, via email, send a message with subject or body 'help' to
email@hidden
You can reach the person managing the list at
email@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Fed-talk digest..."
Today's Topics:
1. Re: mail uses old x.509 certificate (Ron Broersma)
2. Re: mail uses old x.509 certificate (Shawn A. Geddis)
3. Re: OWA/AF Portal Access on Mac... this should be simple
(Shawn A. Geddis)
----------------------------------------------------------------------
Message: 1
Date: Sun, 8 Mar 2009 19:14:59 -0700
From: Ron Broersma <email@hidden>
Subject: Re: [Fed-Talk] mail uses old x.509 certificate
To: "Shawn A. Geddis" <email@hidden>
Cc: email@hidden, Paul Derby <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset="us-ascii"
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4936 bytes
Desc: not available
Url : http://lists.apple.com/mailman/private/fed-talk/attachments/20090308/08ec5a38/smime-0001.bin
------------------------------
Message: 2
Date: Mon, 9 Mar 2009 01:41:30 -0400
From: "Shawn A. Geddis" <email@hidden>
Subject: Re: [Fed-Talk] mail uses old x.509 certificate
To: Ron Broersma <email@hidden>
Cc: Fed Talk <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset="us-ascii"
Ron,
Response inline below...
On Mar 8, 2009, at 10:14 PM, Ron Broersma wrote:
> Shawn,
>
> I also found the certificate selection situation somewhat non-
> intuitive and confusing. I suspect that Paul's issue is that he
> didn't "Show Expired Certificates", and that's why he can't find
> them. I've run into the same thing a number of times before.
>
> Your example of the "security" command is good, but I would
> recommend adding the "-a" option, to show ALL certificates, and not
> just the first match. Since the first match is often NOT the one
> that you want, it can be confusing, because it will often give you
> an expired cert even though there are valid certs in the keychain.
> It would be a lot less confusing if it returned "best match" instead
> of "first match", so a valid cert would have precedence over an
> expired or otherwise invalid cert.
Sure, showing all certificates would be great in many cases. I
understand and appreciate your attempt at trying to simplify the
process, but actually it is difficult to determine which is a "Best
Match". I believe many would have alternate definitions of which they
feel is a "Best Match". You can have multiple certificates
(identities actually) which are valid at any given time. Some issue
new _replacement_ Identities prior to the expiration of the previous
one. Also, many have multiple valid identities issued by different
CAs --- e.g. DoD, VeriSign, Thawte, Entrust, etc. Which of those
would be the "Best Match" now becomes an even much more difficult one
-- depends on the context of the Sender's intent at that moment.
You can have multiple (personal) Keychains with multiple Identities
all valid at any given time.
> The address book has the same problem.
Currently, Address Book, unfortunately displays the first certificate
found by searching ('security find-certificate -e <EmailAddress>')
with the email address defined in the address field and not the first
one which is currently valid.
> It is just as bad as the "security" command, in that it always seems
> to prefer invalid certs over ones that are valid.
Keep in mind that it is not the case that Certs (Identities) are of no
value after they _expire_. It is frequently the case that folks need
to re-read encrypted email which was encrypted with a Certificate that
is _now_ expired, but was not at the time. If you delete an expired
identity, you would not be able to read those older encrypted messages.
The _security_ command is not _bad_ when it gives you exactly what you
are looking for from your current Keychains -- as defined in the
current keychain list. What is challenging is the results may not
have been what you were looking for without performing the appropriate
search.
> In order for Address Book to display the correct cert for a given
> email address, you have to rummage around all your keychains and
> delete all expired certs that match that email address. That really
> seems backwards. Why is this manual keychain maintenance required
> in order to get the right certs to display in Address Book?
As noted earlier, Address Book unfortunately displays the first
certificate found by searching with
'security find-certificate -e <EmailAddress>'
I would love to see the behavior better reflect a valid email
Identity. Right now, it will show the _check mark_ indicating a
certificate is present in the system which also has the corresponding
email address in it. Note that right now that would mean that even
your MobileMe (@mac.com -or @me.com) email address has a _check mark_
next to it even though MobileMe does not provide a Certificate with
the Extended Key Usage for Digital Signature.
I had submitted a RADAR on that and am tracking it.
> Also, can you explain the relationship between what Apple Mail
> chooses for a certificate, vs. what Address Book displays?
Apple Mail will use the first _OS Validated_ certificate corresponding
with the email address (RFC822Name) used for the account you are
sending from as well as the recipient you are sending to.
Address Book (as noted earlier) is displaying the first certificate
corresponding with the email address (RFC822Name) found across all
your keychains.
> Is there any correlation?
Frequently not with all of the Identities that we all have now a days.
> Paul's email implies that a user would intuitively assume that the
> cert used in signing an email would be the one displayed in the
> Address Book. Is there really any relationship, or do these
> separate applications have independent logic in how they choose
> which cert to use?
As noted multiple times now in this email message (hopefully the
replication will help reinforce this point), Mail will use the first
_OS Validated_ certificate corresponding with the email address
(RFC822Name) used for the account you are sending from as well as the
recipient you are sending to.
> If Apple Mail is "never allowed (by the OS) to utilize any
> certificate / identity that does not successfully pass the various
> tests", why wouldn't you make Address Book operate the same way, so
> that a user trying to diagnose problems like this won't be confused
> by the different results of these apps? It would be nice if Address
> Book displayed the same cert that Apple Mail would choose for
> digital signature or encryption for a given email address.
I Agree with that if you have ONLY One identity valid for Digital
Signature. Remember that you can have multiple certificates
(identities actually) which are valid at any given time. Some issue
new _replacement_ Identities prior to the expiration of the previous
one. Also, many have multiple valid identities issued by different
CAs --- e.g. DoD, VeriSign, Thawte, Entrust, etc. Which of those
would be the "Best Match" now becomes an even much more difficult one
-- depends on the context of the Sender's intent at that moment.
Forcing use of a specific Certificate
If you absolutely want Mail to use One Valid Cert over another, then
you can create an Identity Preference for the mapping of email address
to which certificate you prefer to use (assuming it passes all of the
tests for being valid). Note that when you initiate the New Identity
Preference... dialog, it notes the first entry is "Location or Email
Address" -- 'Enter the location (URL) or email address for which a
certificate is required.'
- Shawn
_____________________________________________________
Shawn Geddis - Security Consulting Engineer - Apple Enterprise
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.apple.com/mailman/private/fed-talk/attachments/20090309/9460a09b/attachment-0001.html
------------------------------
Message: 3
Date: Mon, 9 Mar 2009 03:09:30 -0400
From: "Shawn A. Geddis" <email@hidden>
Subject: Re: [Fed-Talk] OWA/AF Portal Access on Mac... this should be
simple
To: Alan Meadows <email@hidden>
Cc: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset="windows-1252"
On Mar 7, 2009, at 8:31 AM, Alan Meadows wrote:
> BUT... when I try to open web mail or other CAC-enabled sites, I get
> the 401 access denied error.
Alan,
Good discussion of this in a previous email message I sent to the
list.... I included it again below...
The reference to 10.5.3 below still stands for 10.5.3-10.5.6.....
- Shawn
_____________________________________________________
Shawn Geddis - Security Consulting Engineer - Apple Enterprise
Begin forwarded message:
> From: "Shawn A. Geddis" <email@hidden>
> Date: July 2, 2008 4:15:55 PM EDT
> To: Fed Talk <email@hidden>
> Subject: [Fed-Talk] [Discussion] (2) Card recognized, but I cannot
> access PKI protected Websites
>
> (Stepping away from vacation long enough to send some critical email)
>
>
> (2) Card recognized, but I cannot access PKI protected Websites
>
> Many of you were already working with your Smart Cards on Mac OS X
> 10.5.0 - 10.5.2, but after you upgraded to 10.5.3, Client-side
> authentication to those sites failed for you.
>
>
> Customers Impacted: Smart Card users who upgraded to Mac OS X 10.5.3
> Required Client Authentication to various PKI protected Web
> portals
> Issued Smart card supports the newer Block Transfer (T=1) type.
>
> If you possibly have a Hybrid card (both CAC and PIV applets),
> you
> may still experience issues even when applying the installer
> from
> Shawn Geddis.
>
> Platform Affected: Mac OS X 10.5.3 - released 05/28/08
>
> Services Affected: Safari 3.1.1
> -- Web Access using Smart Cards to PKI protected US Federal
> Government websites
> (** All other services are NOT affected **)
>
> Delivery Vehicle: Specific fixes have been released as part of Mac
> OS X 10.5.4
> *** Upgrade you system to Mac OS X 10.5.4
> * Safari 3.1.2
> * Keychain Access 4.0.2
>
> Several issues were addressed related to correcting the
> network layer's use of the Identity Preference as well as
> previous
> crashing of Keychain Access when the Identity Preference was
> accessed.
>
>
> Previous User Experience:
> Previous to upgrading to Mac OS X 10.5.3, users were able to
> successfully access PKI protected Government websites using their US
> Federal Government Smart Cards (i.e. DoD -> CAC). In some cases,
> the user would need to manually configure an association between
> which Certificate to use for the specific URL they were accessing.
>
> Related Change in 10.5.3 Safari:
> * Fundamental changes within Mac OS X on how Client-side
> Certificates are handled
> Safari, Mac OS X 10.5.3: Changes in client certificate
> authentication
> http://support.apple.com/kb/HT1679
>
>
> User Experience:
> Mac OS X 10.5.2 (and earlier) / Safari:
> Safari 3 automatically sends the first available client
> certificate in your keychain
>
> Mac OS X 10.5.3 (and later) / Safari:
> You will be prompted to select a client certificate when server
> requests it.
> An Identity Preference is then created for the
> associated URL and Cert.
>
>
> Server Side Configuration Caveat:
> Safari may not prompt you to select a client certificate if the
> server you are attempting to authenticate to is configured to
> *optionally* accept (rather than require) client authentication.
> Many of the US Federal Government web servers are configured for
> *optional* rather than *required*, since there is still a transition
> from User/Pass over to Smart Cards.
>
> System will auto create Identity Preference *IF* Server configured
> for *required*
> As noted in the KBase article referenced above, when accessing a
> website configured as *required*, Safari will prompt the user for
> the appropriate certificate to use for client authentication, but
> ONLY if it is configured as *required*.
>
> Manually Creating Identity Preferences -- Server configured for
> *optional*
> In this case you can force a particular client certificate to be
> sent by manually creating an identity preference item for the
> desired server authentication. Note that it is important to know
> the correct URL for the actual authentication process which may
> significantly differ from the standard login URL.
>
> For example, if you are authentication to AKO:
>
> The website URL is: https://www.us.army.mil/
>
> The CAC Login URL is: https://akocac.us.army.mil/
>
> NOTE:
> It is best to not try and fully qualify the complete URL, but rather
> just include the FQDN - Fully Qualified Domain Name for the server
> you are authenticating to. Also, be careful and ensure you have
> terminated the URL with the "/" to complete the proper host
> specification. For example, do not just enter the above URL as https://akocac.us.army.mil <https://akocac.us.army.mil/>
> without the trailing "/", because it will fail for you.
>
> Also, make sure that you are selecting the *proper* Certificate from
> the card. *Proper* means the certificate expected / required by the
> Server for user authentication. It may require you to check with
> your local Admin or help desk to determine which certificate is
> required for that site.
>
> Since you are manually creating the Identity Preference, you need to
> ensure that you are selecting the right one. The Certificate
> selected is easily changed by opening up the "Identity Preference"
> within your default keychain using Keychain Access and selecting an
> alternative Certificate.
>
>
>
> Troubleshooting:
> To provide you and Apple with the ability to troubleshoot why you
> may still be failing to authenticate to a given server, Apple
> enabled a debug flag which, when enabled, will log identity
> preference information to the System log (/\var/log/system.log).
>
> Enable Identity Preference Debug Mode in 10.5.4 and beyond:
>
> % defaults write com.apple.security LogIdentityPreferenceLookup -
> boolean true
>
>
> When enabled, each identity preference lookup is written as in the
> following example:
>
> Jul 1 18:12:51 /Applications/Safari.app/Contents/MacOS/Safari[386]:
> preferred identity: "User" found for "https://Full.Server.Name/";
>
>
>
> These messages might allow some to correct the host name they
> entered in the manually configured Identity Preference.
>
> If you are still failing, provide these log messages along with your
> Reader and Card information. Quickest way to capture this info is
> to launch Terminal and execute the following command while you have
> your reader attached and card inserted:
>
> % pcsctest
>
> Select the number (typically "1") which corresponds to the reader
> with the card inserted,
>
> ...capture the output from this command and include in your message
> directly to me.
>
>
> - Shawn
> _____________________________________________________
> Shawn Geddis - Security Consulting Engineer - Apple Enterprise
>
>
>
>
>
> Contents of the mentioned Kbase Article mentioned in this post:
>
> Safari, Mac OS X 10.5.3: Changes in client certificate authentication
> http://support.apple.com/kb/HT1679
>
>
> Summary
> Safari 3's handling of client certificate authentication changes in
> Mac OS X 10.5.3 and later.
>
> This improves the security and reliability of client certificate-
> authenticated connections to servers.
>
> Mac OS X 10.5.2 and earlier behavior: Safari 3 automatically sends
> the first available client certificate in your keychain to the
> website.
> Mac OS X 10.5.3 and later behavior: No client certificate is sent
> until you have the opportunity to select the appropriate one to use
> for that site. You will be prompted by Safari 3 to select a client
> certificate at the point where the server requests client
> authentication. After selecting a client certificate, the decision
> is remembered in your keychain as an "identity preference item", and
> you will not be prompted again when returning to the same site.
> Note: Safari may not prompt you to select a client certificate if a
> server is configured to optionally accept (rather than require)
> client authentication. In this case you can force a particular
> client certificate to be sent by creating an identity preference
> item for that server.
>
>
> To manually specify a client certificate be used for a particular
> website:
>
> Open Keychain Access (in Applications/Utilities) and find your
> client certificate. Click the "My Certificates" category to easily
> see available client certificates.
> Control-click the certificate, then choose "New Identity
> Preference..." from the contextual menu.
> A sheet appears in the dialog. Type (or paste) the URL of the page
> that requires the certificate, exactly as it appears in Safari's
> location field (for example, "https://www.apache-ssl.org/cgi/cert-export
> ").
> Note: With Mac OS X 10.5.4 or later, you may specify a partial URL
> to match any page on a server (for example, "https://www.apache-ssl.org/
> ").
> Choose the certificate from the pop-up menu, then click Add to
> create the identity preference. (You may need to click the "All
> Items" category to view the newly created item.)
> To change your decision about which client certificate to use for a
> particular website:
>
> Open Keychain Access (in Applications/Utilities) and find the
> identity preference item for the website in question. Tip: Click the
> "All Items" category and enter the website name in the search field
> in the upper right corner.
> Open the item and select a different certificate from the pop-up menu.
>
> As an alternative to step 2, you can delete the identity preference
> item from the keychain. The next time you visit the site with
> Safari 3 you will be prompted to select your client certificate.
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.apple.com/mailman/private/fed-talk/attachments/20090309/2580a52c/attachment.html
------------------------------
_______________________________________________
Fed-talk mailing list
email@hidden
http://lists.apple.com/mailman/listinfo/fed-talk
End of Fed-talk Digest, Vol 6, Issue 65
***************************************
_______________________________________________
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