Re: private key not available for client_cert_cb

George <whippet0@xxxxxxxxx> · Sun, 10 Jan 2021 23:01:28 -0500

    Hi,

          I had a look at the pkcs11-helper and can see where the
      RSA_METHOD_FLAG_NO_CHECK is being set. It's using a session object
      called pkcs11h_openssl_session_t, which I do
        not see in the libp11 or openSC code.

      Right now I am using the "libp11" DLL (i.e.
      libp11-libp11-0.4.11\src\pkcs11.dll) with my PKCS11 smart card
      middleware DLL. Should I be using the OpenSC pkcs11 DLL instead of
      my middleware DLL if I am using libp1?

      Do you know if it is normal to see exceptions related to the
      PKCS11 function calls in the libp11 code? For example, I can see 
      the following function generate an exception on C_GetSlotList(...)
      multiple times but it eventually is successful.  Is this normal
      behaviour?

      int pkcs11_enumerate_slots(PKCS11_CTX *ctx, PKCS11_SLOT **slotp,
      unsigned int *countp)

      {

      . . .

          rv = cpriv->method->C_GetSlotList(FALSE, NULL_PTR,
      &nslots);

      . . .

      }

      Thanks,

      George

      On 2021-01-08 6:32 p.m., Michael Wojcik wrote:

        From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of George
Sent: Friday, 8 January, 2021 14:35

        The comment indicates that the flag RSA_METHOD_FLAG_NO_CHECK should be set
for smart cards[...]

        However, it is not actually set when I use a debugger to inspect the flag.
Does it need to be set? If so, how is this done?

      If memory serves, the PKCS#11 implementation invoked by the pkcs11 engine is supposed to set it.

See for example this patch to OpenSC's pkcs11-helper library:

https://github.com/OpenSC/pkcs11-helper/commit/5198bb1e557dfd4109bea41c086825bf6ebdd9f3

(That patch actually is to set a different flag, but it shows the code in question.)

I know, that's probably not terribly helpful.

If you do a web search for something like

        pkcs11 "RSA_METHOD_FLAG_NO_CHECK"

you'll probably find a number of hits where other people ran into similar problems.

Isn't PKCS#11 grand? If you're bored with all the interoperability problems of X.509, PKIX, and TLS, we have good news!

--
Michael Wojcik