Thanks for following up.
1. OK. I was hoping to get a handle on the token with the --cert
"<token>:<nickname>" format.

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

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