On 12/1/18 3:29 AM, Sumit Bose wrote:
> On Fri, Nov 30, 2018 at 03:38:55PM -0700, Orion Poplawski wrote:
>> On 11/30/18 6:14 AM, Sumit Bose wrote:
>>> On Thu, Nov 29, 2018 at 02:03:09PM -0700, Orion Poplawski wrote:
>>>> On 11/28/18 11:29 PM, Sumit Bose wrote:
>>>>> On Wed, Nov 28, 2018 at 04:57:17PM -0700, Orion Poplawski wrote:
>>>>>> I configured a YubiKey on Windows using the YubiKey minidriver
>>>>>> following certificates:
>>>>>> - my "orion" certificate - went into slot 9a PIV Auth
>>>>>> - A MacOS keychain cert per their docs - when into slot 9d Key
>>>>>> - Another auth certificate for "orion-admin" - went
into slot 82
>>>>>> I'm able to authenticate on Windows as either orion or
orion-admin, but on
>>>>>> Linux with sssd it does not see the orion-admin certificate.
What needs to
>>>>>> happen to support this?
>>>>> Which version of SSSD are you using?
>>>> On F29:
>>>> I get somewhat different behavior. First the gdm login screen presents
>>>> - Certificate for Key Management
>>>> - Certificate for PIV Authentication
>>>> but still does not list the admin cert. Also, I don't believe it
>>>> the Key Management cert because it is not flagged for smart card
>>> Do you mean the labels 'Certificate for PIV Authentication' and
>>> 'Certificate for Key Management' by 'flagged'?
>>> SSSD only looks at the content of the certificate and by default uses
>>> everything with key usage digitalSignature and extended key usage
>>> clientAuth. With F29 you can modify this by adding mapping and matching
>>> rules to sssd.conf, see the 'CERTIFICATE MAPPING SECTION' in man
>>> sssd.conf for details.
>>>>> Can you sent the output of
>>>>> p11tool --list-all --provider opensc-pkcs11.so
>>> The slots for the retired keys are not visible. I've found
>>> a command which made the slots visible for PKCS#11 on my Yubikey.
>>> Nevertheless the type is still data even after importing a certificate
>>> with 'yubico-piv-tool -a import-certificate'. Maybe this is
>>> when using the Windows driver?
>> I finally figured out the this was suggesting writing the key history object
>> to the yubikey. However, we are using the Yubikeys in a mode where we
>> have (or know) the management key - so I don't seem to be able to write the
>>> Since you already reached out to Yubico you might want to ask as well
>>> what needs to be done to make the certificates and private keys stored
>>> in the retired slots properly available as certificate and private key
>>> on the PKCS#11 level.
>> I was hoping we could somehow make use of the Yubico PKCS#11 provider module?
>> Using it appears to report all of the slots at least:
>> # p11tool --list-all --provider libykcs11.so
>> Object 0:
>> Type: Unknown
>> Label: X.509 Certificate for PIV Authentication
>> Object 30:
>> Type: Public key (RSA-2048)
>> Label: Public key for Key Management
>> ID: 03
>> But sssd doesn't appear to like it:
>> # /usr/libexec/sssd/p11_child -d 10 --debug-fd=1 --nssdb=/etc/pki/nssdb --pre
>> (Fri Nov 30 14:38:04:069338 2018) [[sssd[p11_child]]] [main] (0x0400):
>> p11_child started.
>> (Fri Nov 30 14:38:04:069604 2018) [[sssd[p11_child]]] [main] (0x2000):
>> Running in [pre-auth] mode.
>> (Fri Nov 30 14:38:04:069853 2018) [[sssd[p11_child]]] [main] (0x2000):
>> Running with effective IDs: .
>> (Fri Nov 30 14:38:04:070075 2018) [[sssd[p11_child]]] [main] (0x2000):
>> Running with real IDs .
>> (Fri Nov 30 14:38:04:073047 2018) [[sssd[p11_child]]]
>> [init_verification] (0x0040): X509_LOOKUP_load_file failed
>> [error:0B084088:x509 certificate
>> routines:X509_load_cert_crl_file:no certificate or crl found].
> I guess you tried this on F29 where the OpenSSL build is used. Here you
> have to use '--nssdb=/etc/sssd/pki/sssd_auth_ca_db.pem' or to a
> different file which contains your CA certificates.
> Additionally it looks like libykcs11.so does not come with a p11-kit
> config file, so you have to add something like
> cat > /usr/share/p11-kit/modules/ykcs11.module << END_END
> module: /usr/lib64/libykcs11.so.1
> One RHEL/CentOS 7 you have to add it to /etc/pki/nssdb.
yeah, I started work on p11-kit integration and filed
to do that. But the real
issue is that libykcs11.so is not a (fully) working PKCS#11 implementation.
It appears to support being a ssh-agent plugin but that's about it. See below
again for more info. So I'm back to trying to figure out how to get the Key
History object added to our keys.
>> (Fri Nov 30 14:38:04:073234 2018) [[sssd[p11_child]]] [do_work]
>> (0x0040): init_verification failed.
>> (Fri Nov 30 14:38:04:073469 2018) [[sssd[p11_child]]] [main] (0x0040):
>> do_work failed.
>> (Fri Nov 30 14:38:04:073682 2018) [[sssd[p11_child]]] [main] (0x0020):
>> p11_child failed!
>> And indeed it seems to be an incomplete implementation:
>> # p11tool --export
>> --debug 100 --provider libykcs11.so
>> |<3>| ASSERT: pkcs11.c[pkcs11_import_object]:2120
>> debug: ykcs11.c:1259 (C_GetAttributeValue): In
>> debug: objects.c:398 (get_doa): For data object 0, get
>> debug: objects.c:436 (get_doa): VALUE TODO!!!
>> debug: ykcs11.c:1286 (C_GetAttributeValue): Unable to get attribute 0x11 of
>> object 0
>> debug: ykcs11.c:1291 (C_GetAttributeValue): Out
>> |<3>| ASSERT: pkcs11.c[pkcs11_import_object]:2134
>> debug: ykcs11.c:1460 (C_FindObjectsFinal): In
>> debug: ykcs11.c:1485 (C_FindObjectsFinal): Out
>> debug: ykcs11.c:663 (C_CloseSession): In
>> debug: ykcs11.c:688 (C_CloseSession): Out
>> |<3>| ASSERT: pkcs11.c[gnutls_pkcs11_obj_export3]:1376
>> Error in pkcs11_export:562: The requested data were not available.
>> I've filed https://github.com/Yubico/yubico-piv-tool/issues/175
Which object to do want to export #0 or #27? Both objects match the
PKCS#11 URI you used:
debug: ykcs11.c:1385 (C_FindObjectsInit): Removing object 91 from the list
debug: ykcs11.c:1395 (C_FindObjectsInit): 2 object(s) left after attribute matching
and object #0 is picked:
debug: ykcs11.c:1399 (C_FindObjectsInit): Out
debug: ykcs11.c:1410 (C_FindObjects): In
debug: ykcs11.c:1435 (C_FindObjects): Can return 1 object(s)
debug: ykcs11.c:1451 (C_FindObjects): Returning object 0
However I guess that the object you were looking for is #27. To select
this you should add the id or the type to the URI.
In general I think it would be best if Yubico can work with OpenSC
upstream to allow OpenSC to access the full potential of the Yubikeys in
an easy way.
> Orion Poplawski
> Manager of NWRA Technical Systems 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane orion(a)nwra.com
> Boulder, CO 80301