On Sunday, September 04, 2016 18:00:16 George Wash wrote:
> Thanks for following up.
> 1. OK. I was hoping to get a handle on the token with the --cert
> "<token>:<nickname>" format.

Nobody has implemented it yet. I guess we need to improve SelectClientCert()
to support loading certificates from HW slots:

https://github.com/curl/curl/blob/72abf4f5/lib/vtls/nss.c#L1011

You can have a look at the implementation of 'certutil -h' in NSS:

https://dxr.mozilla.org/mozilla-beta/source/security/nss/cmd/certutil/certutil.c#2981

> 2. I'm not sure whether this is expected. I've been using the NSS tools for
> years with hardware modules and this is the first time I've ever seen the
> 'sql:' prefix. Pardon my ignorance, is this a curl specific construct?

Not really. This is what certutil's man page says about the -d option:

    -d [prefix]directory

        Specify the database directory containing the certificate and
        key database files.

        certutil supports two types of databases: the legacy security
        databases (cert8.db, key3.db, and secmod.db) and new SQLite
        databases (cert9.db, key4.db, and pkcs11.txt).

        NSS recognizes the following prefixes:

        * sql: requests the newer database

        * dbm: requests the legacy database

        If no prefix is specified, the default type is retrieved from
        NSS_DEFAULT_DB_TYPE. If NSS_DEFAULT_DB_TYPE is not set then dbm:
        is the default.

... but the fact that libcurl uses the "sql:" prefix unconditionally is
something we could improve to cover cases like this.

> I agree this could be part of the issue here.
>
> I would like to continue on the smartcard,NSS,curl path.
>
> Although are there any other proven stacks that integrate curl with a
> smartcard from a CLI interface? E.g. curl/openssl build?

You can use 'curl --engine ...' to load a PKCS#11 engine of OpenSSL but
I have never tried it myself.

Kamil

> On Sep 3, 2016 5:04 AM, "Kamil Dudka" <kdudka_at_redhat.com> wrote:
> > On Friday, September 02, 2016 20:17:51 George Wash wrote:
> > > curl version: curl-7.43.0-4.fc23.x86_64
> > >
> > > I have some test certs/private keys in the certificate database that I
> >
> > have
> >
> > > been testing mutual auth with curl successfully.
> > >
> > >
> > > [root_at_localhost foo]# certutil -L -d sql:$SSL_DIR
> > >
> > > Certificate Nickname Trust
> > > Attributes
> > >
> > > SSL,S/MIME,JAR/XPI
> > >
> > > cacert CT,C,C
> > > dbguy u,u,u
> > > pg u,u,u
> > >
> > > [root_at_localhost foo]# modutil -list -dbdir .
> > >
> > > Listing of PKCS #11 Modules
> > > -----------------------------------------------------------
> > >
> > > 1. NSS Internal PKCS #11 Module
> > >
> > > slots: 2 slots attached
> > >
> > > status: loaded
> > >
> > > slot: NSS Internal Cryptographic Services
> > >
> > > token: NSS Generic Crypto Services
> > >
> > > slot: NSS User Private Key and Certificate Services
> > >
> > > token: NSS Certificate DB
> > >
> > > 2. test
> > >
> > > library name: /usr/lib64/pkcs11/libcoolkeypk11.so
> > >
> > > slots: 1 slot attached
> > >
> > > status: loaded
> > >
> > > slot: OMNIKEY AG CardMan 3121 00 00
> > >
> > > token: GEORGE.WASH.DELL.139219165
> > >
> > > -----------------------------------------------------------
> > >
> > >
> > > [root_at_localhost foo]# certutil -L -d "sql:$SSL_DIR" -h
> > > "GEORGE.WASH.DELL.139219165"
> > >
> > > Certificate Nickname Trust
> > > Attributes
> > >
> > > SSL,S/MIME,JAR/XPI
> > >
> > > pg u,u,u
> > > dbguy u,u,u
> > > cacert CT,C,C
> > >
> > >
> > > [root_at_localhost foo]# certutil -L -d "$SSL_DIR" -h
> > > "GEORGE.WASH.DELL.139219165"
> > >
> > > Certificate Nickname Trust
> > > Attributes
> > >
> > > SSL,S/MIME,JAR/XPI
> > >
> > > Enter Password or Pin for "GEORGE.WASH.DELL.139219165":
> > > GEORGE.WfASH.DELL.139219165:CAC ID Certificate u,u,u
> > > GEORGE.WASH.DELL.139219165:CAC Email Signature Certificate u,u,u
> > > GEORGE.WASH.DELL.139219165:CAC Email Encryption Certificate u,u,u
> >
> > I see two differences between your certutil commands and what (lib)curl
> > does:
> >
> > 1. You are using the -h option of certutil but there is no equivalent
> > option
> > of (lib)curl yet, at least not if compiled against NSS.
> >
> > 2. The certificates do not seem to be listed if you use the "sql:" prefix.
> > Is this expected? If yes, this could be a problem because libcurl inserts
> > the "sql:" prefix before $SSL_DIR unconditionally.
> >
> > Kamil
> >
> > > [root_at_localhost foo]# curl -v --cert "GEORGE.WASH.DELL.139219165\:CAC ID
> > > Certificate:<PIN>" https://localhost.localdomain:10443/
> > > * Trying 127.0.0.1...
> > > * Connected to localhost.localdomain (127.0.0.1) port 10443 (#0)
> > > * Initializing NSS with certpath: sql:/root/foo
> > > * CAfile: /etc/pki/tls/certs/ca-bundle.crt
> > >
> > > CApath: none
> > >
> > > * NSS: client certificate not found: GEORGE.WASH.DELL.139219165:CAC ID
> > > Certificate
> > > * NSS error -12271 (SSL_ERROR_BAD_CERT_ALERT)z
> > >
> > >
> > > [root_at_localhost foo]# curl -v --cert "GEORGE.WASH.DELL.139219165\:CAC ID
> > > Certificate" https://localhost.localdomain:10443/
> > > * Trying 127.0.0.1...
> > > * Connected to localhost.localdomain (127.0.0.1) port 10443 (#0)
> > > * Initializing NSS with certpath: sql:/root/foo
> > > * CAfile: /etc/pki/tls/certs/ca-bundle.crt
> > >
> > > CApath: none
> > >
> > > * NSS: client certificate not found: GEORGE.WASH.DELL.139219165:CAC ID
> > > Certificate
> > > * NSS error -12271 (SSL_ERROR_BAD_CERT_ALERT)
> > >
> > > [root_at_localhost foo]# curl -v --cert "GEORGE.WASH.DELL.139219165\:CAC ID
> > > Certificate" --pass <PIN> https://localhost.localdomain:10443/
> > > * Trying 127.0.0.1...
> > > * Connected to localhost.localdomain (127.0.0.1) port 10443 (#0)
> > > * Initializing NSS with certpath: sql:/root/foo
> > > * CAfile: /etc/pki/tls/certs/ca-bundle.crt
> > >
> > > CApath: none
> > >
> > > * NSS: client certificate not found: GEORGE.WASH.DELL.139219165:CAC ID
> > > Certificate
> > > * NSS error -12271 (SSL_ERROR_BAD_CERT_ALERT)
> > >
> > > [root_at_localhost foo]# curl -v --cert "CAC ID Certificate" --pass <PIN>
> > > https://localhost.localdomain:10443/
> > > * Trying 127.0.0.1...
> > > * Connected to localhost.localdomain (127.0.0.1) port 10443 (#0)
> > > * Initializing NSS with certpath: sql:/root/foo
> > > * CAfile: /etc/pki/tls/certs/ca-bundle.crt
> > >
> > > CApath: none
> > >
> > > * NSS: client certificate not found: CAC ID Certificate
> > > * NSS error -12271 (SSL_ERROR_BAD_CERT_ALERT)
> > >
> > > On Fri, Sep 2, 2016 at 3:50 AM, Kamil Dudka <kdudka_at_redhat.com> wrote:
> > > > On Thursday, September 01, 2016 23:10:17 George Wash wrote:
> > > > > I'm trying to use curl on fedora 23 with NSS coolkey and a CAC smart
> > > >
> > > > card.
> > > >
> > > > > Want to use a credential on the smart card for mutual auth TLS.
> > > > >
> > > > > After using modutil I can see and list my certs from the token
> >
> > attached
> >
> > > > to
> > > >
> > > > > the NSS certdb.
> > > > >
> > > > > I've set the SSL_DIR to the path to my cert db?
> > > > >
> > > > > My build of curl seems to have the fix where a cert nickname can
> >
> > have a
> >
> > > > ':'
> > > >
> > > > > but needs escaping with a \. This is helpful because the --cert
> > > > > "token\:cert nickname:password" seems to be parsing the token and
> >
> > cert
> >
> > > > > nickname correctly. However I get an error that the token:cert
> >
> > cannot be
> >
> > > > > found in the cert database.
> > > >
> > > > Have you tried to pass just the nickname to the --cert option of curl?
> > > >
> > > > You can use the --pass option to specify the password.
> > > >
> > > > > Has anyone had luck with an NSS build of curl and a smart card from
> >
> > the
> >
> > > > > command line (without vectoring off to using libcurl)?
> > > >
> > > > I have no first-hand experience with that, neither any HW to try it
> >
> > out.
> >
> > > > > Are there any other avenues I should consider here?
> > > >
> > > > Please paste the full output of 'certutil -L -d sql:$SSL_DIR'.
> > > >
> > > > Kamil
> > > >
> > > > > Thanks
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-users
FAQ: https://curl.haxx.se/docs/faq.html
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-09-05