[SmartcardServices-Users] Odd Keychain CAC and Certificate behavior

Fri Aug 24 06:13:44 PDT 2018

Centrify also doesn’t do thorough certificate chain validation based on our experience. We marked the FBCA untrusted and added an alternate certificate to the validation chain. Centrify saw the “untrusted” FBCA and determined our PIV cards were not trusted instead of properly finding the alternate validation chain we provided in AD. We reported this to Centrify three years ago. We are only now seeing a potential resolution in the GA release. Each time they told us to was fixed, it wasn’t.

Walter
--
Walter Rowe, Acting Chief
Infrastructure Services Division
OISM / NIST / US Dept of Commerce
Email: walter.rowe at nist.gov<mailto:walter.rowe at nist.gov>
Office: 301.975.2885
Mobile: 202.355.4123

On Aug 24, 2018, at 9:07 AM, Rowe, Walter (Fed) <walter.rowe at nist.gov<mailto:walter.rowe at nist.gov>> wrote:

I agree regarding #2 and #3. Centrify does not use the CryptoToken or Keychain APIs properly in my opinion. For example, when using Centrify vs native AD binding, Apple Mail cannot find recipient certificates in AD. Apple Mail is asking Keychain for the certificates. Centrify is the glue to AD and is not plugging itself into Keychain so the lookup fails. If you remove Centrify and use native macOS AD binding, Keychain finds the cert for each recipient in AD as expected and Apple Mail becomes a first class citizen for S/MIME email. Centrify needs to update their client agents to properly plug into macOS. Open a support case with Centrify and make lots of noise.

Walter
--
Walter Rowe, Acting Chief
Infrastructure Services Division
OISM / NIST / US Dept of Commerce
Email: walter.rowe at nist.gov<mailto:walter.rowe at nist.gov>
Office: 301.975.2885
Mobile: 202.355.4123

On Aug 24, 2018, at 8:18 AM, Miller, Timothy J. <tmiller at mitre.org<mailto:tmiller at mitre.org>> wrote:

In re: (1) the FBCA cert--that's a normal error.  The FPKI is a bridge PKI across multiple agencies including the DoD.  The root cert for bridge PKIs isn't actually used for anything.  Mark the FBCA root untrusted on the problem client, but don't delete it.

(It happens because Windows machines prefer paths with nameConstraints, and so will include a path to the FBCA root over any other path.  Typically, this spreads in S/MIME signature cert bundles--receiving S/MIME MUAs extracts the sender's cert bundle and adds it to the local pool, where it causes problems for other applications.  There's a discussion of this on militarycac.com<http://militarycac.com/> and on the IASE PKI portal.)

In re: (2) and (3)--this is a middleware issue, probably related to PIN caching.  That's one for Centrify to address.

In re: (4) and the keychain list--IME that's just how Keychain Access works.  It doesn't refresh the keychain list. (4a) sounds like another middleware problem.

-- T

On 8/23/18, 10:31 PM, "SmartcardServices-Users on behalf of Peter Walsh" <smartcardservices-users-bounces at lists.macosforge.org<mailto:smartcardservices-users-bounces at lists.macosforge.org> on behalf of peter.walsh at jackpinetech.com<mailto:peter.walsh at jackpinetech.com>> wrote:

   Our team has been seeing some very odd behavior with certs & CACs over the past few months that we can not resolve. We operate a DoD site with PKI auth so we are constantly testing and consuming using various configs. Multiple users have had this problem.

   The config in question is
   macOS 10.13.5 and 10.13.6
   Centrify Express for Smart Card 5.4.2 (542668)
   Chrome (latest) & Safari (latest)
   Oberthur and G&D Smart Cards

   Cert Behaviors
   ===========
   1) The server side SSL cert come up as untrusted because Keychain Access.app traces it up thru a intermediate DoD Root to the Fed Bridge root, not the correct path to the DoD Root CA 3 (this root CA is in keychain Access.app and explicitly trusted).
    It is like Keychain Access.app is matching on name rather than cert. Not sure how we get to this state but the only resolution is to reboot the system. It has occurred with multiple sites. At one point I was able to open two sessions to the same site and in
    a side by side windows show each resolving the cert thru a different path. (picture attached, not sure if it will make it on the mail list.)

   CAC Behaviors
   ============
   2) User successfully authenticates to the site with their CAC. After ~20-30 seconds on a page, when he clicks on a link, he is asked to enter his PIN to unlock his CAC again. This continues during the entire session. While the is happening, if
    he opens Keychain Access.app, the CAC shows as locked.

   3) User unlocks CAC in Keychain Access.app, launches the browser, then tries to authenticate to the site. The browser just hangs until the CAC is removed from the reader, then the slider will appear to select from the other soft certs on the system
    (e.g. ECA).

   4) Insert CAC into reader while Keychain Access.app is open and it never appears. This is different from past behavior of Keychain Access.app.
   4a) Quit Keychain Access.app, reinsert CAC. The CAC appears on the left as a keychain but nothing appears on the right; clicking the lock prompts for PIN but doesn’t actually unlock.
    Browser does not see any cert; removing CAC from reader allows the browser slider to appear and see the other soft certs on the system.

   Thanks for any input. We are going to try some other middleware but otherwise not sure of options.

   Peter Walsh
   Jackpine Technologies Corp.
   peter.walsh at jackpinetech.com<mailto:peter.walsh at jackpinetech.com>
   c. 617/816-6001

_______________________________________________
SmartcardServices-Users mailing list
SmartcardServices-Users at lists.macosforge.org<mailto:SmartcardServices-Users at lists.macosforge.org>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.macosforge.org%2Fmailman%2Flistinfo%2Fsmartcardservices-users&data=02%7C01%7Cwalter.rowe%40nist.gov%7Cb8a1e9e472ae4b383ff308d609bce4cb%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636707104227575010&sdata=XlVaVnLAwMKwt%2Fzjlqq9lSDc%2F1yzn5PH%2FjN6hkA%2FOC4%3D&reserved=0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/smartcardservices-users/attachments/20180824/29605007/attachment-0001.html>