Red Hat Bugzilla – Bug 188407
Please compile with --enable-extendedapdu
Last modified: 2007-11-30 17:11:30 EST
Description of problem:
While doing some tests with Athena RSA smartcards with an Athena smartcard
reader, I found that openssl wouldn't generate an RSA key on the card. After
downloading the pcsc-lite source, and rebuilding with --enable-extendedapdu,
it worked correctly.
Version-Release number of selected component (if applicable):
Always, with this hardware/smartcard combination
Steps to Reproduce:
1. Install pcsc-lite-1.3.0
2. Download and install reader drivers
configure and install.
3. Install opensc (plus libp11 and engine_pkcs11 from
http://www.opensc.org, I'll file another bug on this)
4. Start pcsc-lit daemon
5. Download Athena PKCS#11 binary from:
This should be uncompressed and go into /usr/lib/pkcs11
6. Grab latest version of easy-rsa:
7. Now you can use easy-rsa in order do manage your PKI
Start with editing vars.
You have a CA up and running.
Next, insert your new token:
./pkitool --pkcs11-slots /usr/lib/pkcs11/libasepkcs.so
Record your slot id.
Initialize your token:
./pkitool --pkcs11-init /usr/lib/pkcs11/libasepkcs.so [slot]
Enrol a new certificate:
./pkitool --pkcs11 /usr/lib/pkcs11/libasepkcs.so [slot] 00
All appears to work, until the last (certificate generation) step, which
produces a lot of errors and doesn't generate the certificate or private key.
Certificate is generated correctly.
That option just increases the size of the APDU buffer. It should have no
Looks innocent enough, but I'll ping upstream beacause if there are no adverse
side effects, I'm wondering why it's not on by default, nor are Debian or SuSE
pcsc-lite packages built with that option.
No problem - seems like a good approach. FWIW: apparently the Gentoo e-builds
turn this option on by default.
Ludovic (Cc'd) replied and said he'd get back to me on this. Some related info:
As I said in the message you refer to it is mainly a problem of memory and CPU
What you SHALL NOT do in install a libpcsclite and a pcscd with differen
configuration (libpcsclite with support of extended APDU and pcscd without or
the reverse). The communication between them will just not work.
I am working on integrating a better way to support extended APDU. Extended APDU
will then be active by default in the next pcsc-lite release.
Thanks for the comments, Ludovic.
Having a mismatch between pcscd and libpcsclite is very unlikely to happen with
the FE packages, but how about other applications that use libpcsclite in
general (both in FE and locally compiled)?
Let's say app X was compiled against the current libpcsclite version which uses
the default APDU's. Now, if one rebuilds libpcsclite (and pcscd) using extended
APDU's, would app X break if it's not recompiled against the new libpcsclite?
Anyway, I'm personally fine with waiting for the next version.
You do not have to rebuild your application. libpcsclite is API and ABI
compatible with or without support of extended APDU. Of course you will not have
access to extended APDU if libpcsclite is not compiled with it but I will not
crash. You will just get a SCARD_E_INSUFFICIENT_BUFFER error if your buffer is
too big (Microsoft does not define a SCARD_E_TOO_BIG_BUFFER, Maybe
SCARD_E_INVALID_PARAMETER should be use instead?).
Reassigning to FC maintainer. Based on the 1.3.2 release notes, upgrading to it
would take care of this?
I've finally pushed 1.3.2 to devel, does that take care of the problem, or do we
need to add the flag still?
I am not in a position to test for a couple of weeks, but I have no problems
with this bug being closed if you are confident that this is sorted.
I'm not completely confident, and it doesn't hurt to leave it open until it's
verified. I'll move it to modified. when you get a chance to test it go ahead
hand mark it verified if it works or back to assigned if it doesn't.