On Mon, Dec 03, 2018 at 11:54:44AM -0700, Orion Poplawski wrote:
> 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 with the
> >>>>>> following certificates:
> >>>>>>
> >>>>>> - my "orion" certificate - went into slot 9a PIV Auth
> >>>>>> - A MacOS keychain cert per their docs - when into slot 9d Key
> >>>>>> Management
> >>>>>> - 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:
> >>>>
> >>>> sssd-2.0.0-4.fc29.x86_64
> >>>>
> >>>> I get somewhat different behavior. First the gdm login screen presents
> >>>> two
> >>>> certificates:
> >>>>
> >>>> - Certificate for Key Management
> >>>> - Certificate for PIV Authentication
> >>>>
> >>>> but still does not list the admin cert. Also, I don't believe it should
> >>>> list
> >>>> the Key Management cert because it is not flagged for smart card
> >>>> authentication.
> >>>
> >>> 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
> >>> https://github.com/OpenSC/OpenSC/issues/847#issuecomment-238119888 with
> >>> 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 different
> >>> 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
> >> don't
> >> have (or know) the management key - so I don't seem to be able to write the
> >> object.
> >>
> >>> 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:
> >> URL:
> >> pkcs11:model=YubiKey%20YK4;manufacturer=Yubico;serial=1234;token=YubiKey%20PIV;object=X.509%20Certificate%20for%20PIV%20Authentication%00
> >> Type: Unknown
> >> Label: X.509 Certificate for PIV Authentication
> >> ID:
> ...
> >> Object 30:
> >> URL:
> >> pkcs11:model=YubiKey%20YK4;manufacturer=Yubico;serial=1234;token=YubiKey%20PIV;id=%03;object=Public%20key%20for%20Key%20Management%00;type=public
> >> 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[3904]]]] [main]
> >> (0x0400):
> >> p11_child started.
> >> (Fri Nov 30 14:38:04:069604 2018) [[sssd[p11_child[3904]]]] [main]
> >> (0x2000):
> >> Running in [pre-auth] mode.
> >> (Fri Nov 30 14:38:04:069853 2018) [[sssd[p11_child[3904]]]] [main]
> >> (0x2000):
> >> Running with effective IDs: [0][0].
> >> (Fri Nov 30 14:38:04:070075 2018) [[sssd[p11_child[3904]]]] [main]
> >> (0x2000):
> >> Running with real IDs [0][0].
> >> (Fri Nov 30 14:38:04:073047 2018) [[sssd[p11_child[3904]]]]
> >> [init_verification] (0x0040): X509_LOOKUP_load_file failed
> >> [185090184][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
> > END_END
> >
> > One RHEL/CentOS 7 you have to add it to /etc/pki/nssdb.
>
> yeah, I started work on p11-kit integration and filed
> https://github.com/Yubico/yubico-piv-tool/pull/176 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.
>
> Thanks again.
>
> >
> >> (Fri Nov 30 14:38:04:073234 2018) [[sssd[p11_child[3904]]]] [do_work]
> >> (0x0040): init_verification failed.
> >> (Fri Nov 30 14:38:04:073469 2018) [[sssd[p11_child[3904]]]] [main]
> >> (0x0040):
> >> do_work failed.
> >> (Fri Nov 30 14:38:04:073682 2018) [[sssd[p11_child[3904]]]] [main]
> >> (0x0020):
> >> p11_child failed!
> >>
> >> And indeed it seems to be an incomplete implementation:
> >>
> >> # p11tool --export
> >> 'pkcs11:model=YubiKey%20YK4;manufacturer=Yubico;serial=1234;token=YubiKey%20PIV;object=X.509%20Certificate%20for%20PIV%20Authentication%00'
> >> --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.
bye,
Sumit
>
>
> --
> Orion Poplawski
> Manager of NWRA Technical Systems 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane [email protected]
> Boulder, CO 80301 https://www.nwra.com/
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
