10.11.6 CAC signing not working with 11.0.17 Acrobat

[Predator130]

I have verified that I can sign on a 10.11.5 mac but when the OS is updated to 10.11.6 with the same Acrobat installation signing fails.  The certificates show as valid and are used for login so I know they are valid.  Any solutions so far?

[ronnyj75312535]

Any news about this topic?

[Mouse07410]

PDF signing using smart card (CAC or PIV) works fine on Mac OS X 10.11.6. Tested with Acrobat Pro 11.0.17 and 15.006.30198. For it to work out of box you need a working tokend.

If you do not have a working tokend - then the workaround provided above (adding a PKCS#11 library that accesses the CAC directly) would solve the problem, assuming your PKCS#11 library works correctly.

Currently I'm using Open Source tools (OpenSC and OpenSC.tokend). These tools fully support my workflow for smartcards, including PDF signing, S/MIME (signature and encryption, using Apple Mail and MS Outlook 2011 and 2016), Web sites authentication (Apple Safari, Google Chrome, Firefox using PKCS#11 library opens-pkcs11.so), and smartcard-based computer logon. I did not have to attach a PKCS#11 library, as it is unnecessary when your tokend is good:

Mac OS X 10.11.6 improved PDF signing - before Acrobat was only using SHA1 if the signing key was on a CAC. Now it correctly uses what it's supposed to - SHA256:

For those people who have problems with PDF digital signature - please check what tokend you're using, and try with a working one instead. I did, and you can see the results on the screenshots above.

[MacMama]

Another update to Adobe Acrobat Pro and we STILL CANNOT sign documents if the system is running OS X 10.11.6 and using Centrify to CAC authenticate.  Why Adobe can we add the PKCS#11 module from Centrify to Adobe Acrobat Reader DC and not  Adobe Acrobat Pro??  This needs to be fixed ASAP.

[ronnyj75312535]

A new update to Adobe Reader DC without posotive results, this problem sitll messing around. Are you going to fix this problem or not? For some of us this urgent.

[Mouse07410]

Since I'm successful signing on 10.11.6 with both Acrobat Pro and DC (Classic), it suggests that the problem may be with Centrify tokend. Because I don't seem to need to load any PKCS#11 library at all.

P.S. Authentication works too, and without Centrify. 😉

[Andrea Valle · Accepted solution]

Dear CAC and PIV card users on MacOS computers, here’s an update on our progress to solve the issue that many of you are facing when signing in Adobe Acrobat and Reader after updating Mac OSX to version 10.11.6 or 10.12.

I will provide some technical details at the end if you’re interested, but first we have some important news. We have been working closely with Apple and especially with Kenneth Van Alstyne, the developer who manages the Mac OSX port of the open source CACkey driver, to understand and solve this issue.

Kenneth has just released a new version 0.7.8 of the CACkey driver that should solve this issue and includes several fixes.

It is already available for Download from here: Index of /download/0.7.8

Please give it a run and let us know if it works for you.

Note: this update is specific to CACkey driver users. We heard that some users of the Centrify driver have been impacted as well. We need more help to investigate about it, as it may also require an update to work again. Please consider using CACkey version 0.7.8 until we have more to share on Centrify.

Best regards

Andrea Valle, Sr. Product Manager, Adobe Document Cloud

And now some technical details…*

Adobe Acrobat adopts SHA256 as the default digest algorithm for digital signatures since version 9.1 (2009). However, CACkey drivers before v.0.7.8 don’t support SHA256 when used via Apple Keychain/tokenD, but only the deprecated SHA1 algorithm. To make the signature possible when SHA256 is not supported, Acrobat adopts a fallback mechanism to SHA1.

Apple Mac OSX update 10.11.6 made SHA-2 (which was previously unsupported) as the default hashing algorithm, due to which the behavior of certain crypto API in OSX have changed. For this reason Acrobat started to fail signing: the SHA1 fallback mechanism is impacted by these crypto API changes and fails.

CACKey 0.7.8 for Mac OSX now includes a new PKCS11.tokend module that adds SHA-2 support (SHA256, SHA384, and SHA512), so Acrobat does not have to fallback to SHA1 anymore.

Adobe is working to fix the fallback mechanism in Acrobat due to OSX 10.11.6, but this has no more impact on signing with CACkey driver after the user updates to version 0.7.8.

* Thanks to Kenneth Van Alstyne and Adobe’s Krishna Kumar Pandey for working hard at solving this issue.

[Mouse07410]

Andrea, that is great to hear, thank you!

FYI, the current OpenSC.tokend (see above for the pointers to GitHub) supports SHA-2 family, and ECC (ECDSA tested with MS Outlook, Apple Mail, Safari, Firefox; ECDH not tested). It is also open source.

Regarding PKCS11.tokend included in CACKey,  that would mean that on MacOS 10.12 smartcard support would be in Legacy mode, rather than using new CTK?

[Andrea Valle]

Hi,

I think so but I defer to Kenneth to give you a definitive reply.

Andrea

[Guest]

All:

Joining this conversation.  There was a critical bug in PKCS11.tokend in regards to generating valid SHA-2 headers.  I fixed this and submitted a pull request upstream.  Please test using CACKey 0.7.8, available for download on militarycac.com shortly or available now at:

Index of /download/0.7.8

To answer other questions, CACKey itself is a PKCS#11 module.  The Mac port includes a TokenD to PKCS#11 shim (PKCS11.tokend) provided upstream by Apple's SmartCardServices team.  As of now, there is no CTK to PKCS#11 shim available, so is indeed "legacy".

The Leopard package is for 10.5 only and still supports PowerPC and i386.  The "SLandUp" package is for macOS releases >= 10.6 and supports i386 and x86_64.

Thanks,

Kenny

[Mouse07410]

Kenny, thanks. I see.

The reason for my question is that Sierra bundles its own tokend (pivtoken) with CTK. That combination adds the ability to pair the smartcard with the account, so the entire login (including FileVault2 and Keychains unlock) can be done with a smartcard. That's the "new" mode. The disadvantages are - neither Keychain Access nor the majority of the applications (at least, all of the 3rd-party apps that I know of) can access certs/keys on the smartcard in that mode.

An alternative to the above is installing your own tokend and disabling the pivtoken (which is necessary to avoid interference/conflicts). This would be the "Legacy" mode: you lose the ability and the benefits of pairing, but you get back the ability to use applications (such as Adobe Acrobat) with smartcard. In fact, that's what I'm doing with my Sierra machines, because the ability to use apps is more important than the convenience of one login/unlock with a smartcard. 😉

[Guest]

I totally hear you!  I'm in the same boat, as I have a DoD CAC and a corporate PIV-compliant smartcard which would be wonderful to pair with my account on my Macs for smartcard logon.

Ideally, someone (or I) would write a CTK token (to PKCS#11 shim) that works in parallel with the legacy TokenD, that way if you need TokenD, CTK, or PKCS#11, everything would be happy.  It's certainly something I want to do, but have not had the time to work on it.

Thanks,

Kenny

[Mouse07410]

Kenny, I didn't think you could run the two (Legacy and CTK) in parallel - it seemed to be one or the other. When I installed my tokend without blocking pivtoken first (which I assume disabled CTK?) all hell broke loose... And I don't think enabling/using the pairing can be done by a shim?

Basically, the new Apple pivtoken does not have Keychain interface (does not make the token accessible through it), which breaks all the apps including Adobe Acrobat (and excepting Apple Mail and Safari that know how to interface with the new CTK). I think if more people complain to Apple, they might restore/add that interface, making the current apps work with the smartcards again. As a side benefit, you'd be able to view your token in Keychain Access - which I found to be invaluable when debugging certificate (particularly CA) evaluation incompatibilities between El Capitan and Sierra.

[Guest]

Well, "Legacy" TokenDs and PKCS#11 modules coexist today and have for as long as TokenDs have been around on OS X -- I'm wondering if the real issue has to do with the PIVToken CTK not playing nicely with other "things" like PKCS#11 modules or TokenDs accessing the card at the same time.  Specifically, I'm suspecting that once you "log into" the card with the PIVToken CTK, it expects that session to be exclusive.  When the card gets reset and you "log into" the card with another module, all hell breaks loose, as you say.

I don't see any reason that a CTK and TokenD (and PKCS#11 module) can't be made to work together.  It's just frustrating that there's yet ANOTHER Apple-specific "thing" that crypto vendors have to do on Macs...  and that's coming from a person that exclusively uses macOS on the client-side of things.

Thanks,

Kenny

[Mouse07410]

> I don't see any reason that a CTK and TokenD (and PKCS#11 module) can't be made to work together.

I don't think it's as simple as that - because pivtoken itself is a tokend, so some functionality/capabilities would overlap with the Legacy tokend, and some would not. How then would the system know which of the two tokend's to pass the requests to for things that both happen to support?

I agree with there shouldn't be an issue between a PKCS#11 library and a tokend - and in fact I experience little to none with OpenSC, YKCS11, and my tokend. Tokend serves Mail and Acrobat, while I can run OpenSSL-based CLI apps that use keys on a smartcard.

[Guest]

I'll admit, you seem more knowledgable than I on the subject, but I was of the understanding that CTK was a completely new API and applications have to be written to take advantage of it.  (Hence why Apple's included applications, like Safari already have support, but third party applications don't work.)  In the case of applications supporting both CSSM/CDSA and CTK, I'm not really sure how they would behave if the same token were to be made available via both APIs.  The documentation for CryptoTokenKit has been a little lacking.  Hopefully eventually Apple can shed some light on this, as I'm a little nervous that 10.13 is going to remove TokenD support completely.

Thanks,

Kenny

[Mouse07410]

> CTK was a completely new API and applications have to be written to take advantage of it

Concur.

> In the case of applications supporting both CSSM/CDSA and CTK, I'm not really sure how they would behave if the same token were to be made available via both APIs

The issue I'm concerned with is two tokends - pivtoken (that's incapable of "feeding" the smartcard to Keychain and such) and a legacy tokend (such as your or mine) figthing each other for requests that they both can serve. Rather than one tokend receiving requests via multiple interfaces (which should be trivial ).

> The documentation for CryptoTokenKit has been a little lacking.  Hopefully eventually Apple can shed some light on this,

> I'm a little nervous that 10.13 is going to remove TokenD support completely.

Ah, you're one of those few who do learn from history and past experience?

I just hope the legacy framework would stay with us, so our current code could work.

[SmartGraphicArt]

Having the same issue with DC Pro (and Reader) on Windows 7.

[Car2]

I'm also having this same issue on Windows 10 Enterprise, Adobe Acrobat Pro DC (2015) v 15.006.30508, 90 Meter SmartCard Manager Plus 1.6.35 s on a VDI governement network.  When trying to digitally sign a pdf it will not read my token.  I can self-sign.  I log into my workstation with my token and can digitally sign and encrypt emails.  My certificates are not expired.  This is happening to everyone on base.  Any help would be appreciated!  We need to get this working as soon as possible!

[oscarg61026051]

UPDATE:  Within 10 minutes of posting and re-reading the beginning of this post and running the CACKey driver from page 1. and following the "attach module" steps that is in the notes; the rest was cake and I was able to sign digitally with my CAC. I was hesitant at first to download but after purchasing the subscription and the inability to still not sign. I was in dire need of a solution. That solution was the CACkey driver. 

Once that is installed then hit the "back' button and enter this " /usr/local/lib/pkcs11/cackey.dylib " under attach module and BOOM you have the answer.

*****I too am running into the issue of unable to sign with digital certs using my military CAC while using ADOBE DC.  I have traveled the webs and this forum and as many state ADOBE is not addressing the issue. I am running the latest IOS High Sierra 10.13.2 and Adobe DC will not see the CAC reader and of course the reader is plugged in with the card inserted; verified by logging into websites/military sites that require CAC log in.

[janes_p]

Thanks for the clarification Andrea Valle, and also for the technical background.

Can you clarify a bit more what exactly causes the message "The credential selected for signing is invalid".

Reason: I am working with our Swiss signature provider SwissSign (operated by Swiss Post) to get our certificate to work with Adobe Acrobat (Pro DC, in my case).

Swiss Post support page: Postsuisseid - Postsuisseid (images missing, unfortunately)

[Andrea Valle]

Hi Peter,

I think you should better create a new thread for your issue because it's unrelated to this thread (signing with CAC cards).

Anyways, the message "The credential selected for signing is invalid" can have multiple reasons, the most common of which is that the Key Usage or Extended Key Usage of the SwissSign certificate is not suitable for digitally signing a document.

For example it could be intended only for client authentication or encryption, so Acrobat will deem it as invalid for signing.

Please check this page for more information about this under the 11.0.9 section:

A: Changes Across Releases — Digital Signatures Guide for IT

Regards

Andrea