Red Hat Bugzilla – Bug 266021
curl + nss doesn't work
Last modified: 2014-03-16 23:08:09 EDT
Description of problem:
At least, not how it's used for 'make upload'.
curl -k --cert <your fedora cert> --fail -F name=<some package> -F md5sum=<some
md5sum> -F filename=<some file> https://cvs.fedoraproject.org/repo/pkgs/upload.cgi
With 7.16.4-2.fc8 (openssl) this works.
With 7.16.4-3.fc8 (NSS) this fails with a 403 error.
Version-Release number of selected component (if applicable):
Marking as Fedora 8 blocker since it makes building new packages hard. CC'ing
The problem could be caused by the fact, that curl is still configured to use
/etc/pki/tls/certs/ca-bundle.crt, is there an equivalent cert bundle provided by
nss? If yes, we can switch to use that one.
Daniel, is there needed to do something special except this to make the curl nss
support work as expected?
I can revert the nss switch immediatelly to make the source uploading work again
until we manage to make the nss support work.
Rob Crittenden of Redhat is the one who brought the NSS support to (lib)curl and
I bet he knows far more than me about particular details such as this.
AFAIU, NSS uses a ca cert database file somewhere...
NSS uses its own cert db format.
The workaround is (you need certutil and pkcs12util for that):
Create .nss subdir in your home:
Init NSS db there (if you enter a password you'll need to add it to curl command
certutil -N -d ~/.nss
Convert .fedora.cert to PKCS12 format:
openssl pkcs12 -export -in .fedora.cert -out .fedora.p12 -n <nickname>
Import PKCS12 into the NSS db:
pk12util -i .fedora.p12 -d ~/.nss
curl -k --cert <nickname> --cacert ~/.nss ...
If you initialized the NSS db with a password you'll have to add '--pass <the
password>' to the curl command line.
So basically - curl+NSS does work, but differently.
(In reply to comment #3)
> openssl pkcs12 -export -in .fedora.cert -out .fedora.p12 -n <nickname>
There is typo here - the last option is -name <nickname>
But requiring all of this means that curl has incompatibly changed with the
switch to nss. And not for users of the libcurl API (which would be bad, but
not unheard of), but instead for people using the command-line program. Which
kind of sucks
I agree that it sucks.
The problem with OpenSSL->NSS conversion is that the philosophy behind the two
libraries is quite different so it is pretty hard to make the ported apps to
behave in 100% compatible way. The dependence on NSS cert db is something which
simply cannot be removed without thorough rewriting of NSS.
For loading the client cert from PEM file there is a PKCS#11 module in the works
but I don't know what is its current status and whether it will make it 100%
compatible with the OpenSSL way of loading client certs.
Also for the FIPS-140-2 Level 2 certification to be still valid there might be
some restrictions as to whether this mentioned module would be allowed or not.
We should have a version of libcurl+nss that works with PEM files shortly. We
already solved the problem generally in nss_compat_ossl. Libcurl did the
conversion directly, though.
The nss patch which was applied in curl-7.16.4-3.fc8 has also caused a program
of mine to stop working properly.
This program uses libcurl to retrieve a gzip-compressed http:// url, but the
decoding of the gzip data fails since curl-7.16.4-3.fc8. libcurl only returns
the compressed data instead of the expected decompressed data.
I reverted the default to use NSS back to OpenSSL to avoid breakages. We can
reenable it as soon as curl users will be prepared for it and a clear HOWTO will
I'm letting this bug open to track any changes in the NSS curl support so that
it could be enabled later.
For comment #9 if you aren't using SSL then this change should not affect you.
I have 2 SRPMS ready for testing. This requires some changes to the nss package
to incorporate the PKCS#11 module needed for importing PEM files. I also wrote a
patch against the curl NSS module to change the command-line to load the PKCS#11
module and import PEM files. It should also work if you have an existing NSS
database and certificates/keys.
You can get the two SRPMS from: http://rcritten.fedorapeople.org/files/
To test the Fedora infrastructure once you've built and installed these, find or
create a file you want to upload to your project. In my case this is
nss_compat_ossl. Do an md5sum of the file, then run something like:
curl -k --cert ~/.fedora.cert --fail -F "name=nss_compat_ossl" -F
"md5sum=1dcca23355272056f04fe8bf20edfce0" -F "file=@test"
Here I'm uploading to nss_compat_ossl the file "test" with an md5sum of
The @ before the filename is important.
I tested with the -v argument to curl to get more output.
You have to use the -k argument because:
1. You probably don't have the CA that signed the cert installed
2. The certificate is expired (April 5, 2006!)
3. The CN of the certificate is cvs.fedora.redhat.com, not cvs.fedoraproject.org
Packages built in koji that address the problem:
Closing RAWHIDE as the NSS support in curl shouldn't break things and it's
enabled now. Please reopen if you see something odd with curl related to NSS.
*** Bug 570231 has been marked as a duplicate of this bug. ***