OK - this is working now. Upgrading to the new sqlite style certdb works.

# export NSS_DEFAULT_DB_TYPE="sql"

# mkdir /root/foo2

# cd /root/foo2/

# certutil -N -d .

# export SSL_DIR="/root/foo2"

# modutil -add test -dbdir . -libfile /usr/lib64/pkcs11/libcoolkeypk11.so

# curl -k -v -E "GEORGE.WASH.DELL.139219165\:CAC ID Certificate" --pass
<TOKEN PWD> https://localhost.localdomain:10443

This works, verified client cert gets passed to TLS server in wireshark.

This format works too

# curl -k -v -E "GEORGE.WASH.DELL.139219165\:CAC ID Certificate:<Token
PWD>" https://localhost.localdomain:10443

root_at_localhost foo2]# rpm -qa | grep curl
curl-7.43.0-8.fc23.x86_64
libcurl-7.43.0-8.fc23.x86_64

I have a RHEL 7.x system with curl-7-29-0-32. This version of cURL doesn't
seem to have the escaping of the ':' working correctly. Any idea at what
rev of curl this fix was implemented?

Thanks!

GW

On Mon, Sep 5, 2016 at 9:26 AM, Kamil Dudka <kdudka_at_redhat.com> wrote:

> 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-07