Thanks for searching that up.

Kamil - I see you're one if the curl maintainers for RHEL. Do you know if
this fix will be in RHEL 7.3?

On Sep 7, 2016 4:04 AM, "Kamil Dudka" <kdudka_at_redhat.com> wrote:

> On Tuesday, September 06, 2016 20:44:51 George Wash wrote:
> > 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
>
> Perfect. Thank you for sharing the know-how with us!
>
> > 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?
>
> It seems to be addressed by the following patchset:
>
> https://github.com/curl/curl/compare/35874298e4...bcf1b9dec1
>
> Kamil
>
> > 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