libcurl compiled against gnutls does not support passphrases on SSL client keys. libcurl compiled against openssl does just fine. This makes client keys rather impractical to use with Debian's git-core. Testing this can be done with the following commands: curl -O http://hitler.omgwallhack.org/ssltesting/usercert/chump.pem curl -O http://hitler.omgwallhack.org/ssltesting/testca.crt curl -O http://hitler.omgwallhack.org/ssltesting/usercert/chump-password.pem GIT_SSL_CAINFO=testca.crt GIT_SSL_CERT=chump.pem git clone https://hitler.omgwallhack.org/ssltesting/ssltest.git/ rm -rf ssltest GIT_SSL_CAINFO=testca.crt GIT_SSL_CERT=chump-password.pem git clone https://hitler.omgwallhack.org/ssltesting/ssltest.git/ rm -rf ssltest Curl, compiled against openssl, does the *right* thing: curl -E chump.pem --cacert testca.crt https://hitler.omgwallhack.org/ssltesting/ curl -E chump-password.pem:password --cacert testca.crt https://hitler.omgwallhack.org/ssltesting/ (If anyone happens to want to recreate the server environment, http://hitler.omgwallhack.org/ssltesting/ca.sh will probably help you out.) I don't know what the solution would be for this since I don't really know why git-core Depends: libcurl3-gnutls (>= 7.16.2-1) in Debian in the first place. Manually replacing libcurl-gnutls.so.4.1.0 with libcurl.so.4.1.0 didn't have any other engaging consequences to git besides solving this bug for me, for what it's worth. I've tested a patch that exposes CURLOPT_SSLKEY within git. This library feature appears to do nothing in libcurl[3|4]-gnutls, so I wouldn't suggest anybody else try the same.
I just fixed a firewall misconfiguration, so the above should actually work, now. GnuTLS-compiled libneon appears to be able to decrypt pkcs12, at least, so I suppose libcurl should really be able to do the same. Let me know if I should move on to bugging them about it instead.
reassign 491036 git git-core/1:1.5.6.2-1 quit Hi Joey, Aggh, sorry for the long time without response. Is CURLOPT_SSLKEY still a no-op for libcurl-gnutls? Because I am lazy, please also allow me the liberty of asking: do you know how to make a simple setup to demonstrate this? Yes, you should have! :) But it’s been a couple of years now, so I guess the first thing is to check whether anything’s changed since then. I’d be glad to help however I can. Thanks, Jonathan
User Certificates Support works. However, if the certificate (more correctly the key of the cert) is encrypted, git fails with a bogus error message: olaf@nucky:~$ git clone https://xxx.science-computing.de/prot-anon.git Klone nach 'prot-anon'... Password for 'cert:////home/olaf/mycert.pem': fatal: unable to access 'https://xxx.science-computing.de/prot-anon.git/': error reading X.509 key or certificate file if you look at the command with strace you see a bogus write call to fileid -1 causing the error message above: changing the build dependency from libcurl4-gnutls-dev to libcurl4-openssl-dev fixes the weird behaviour. It smells like a hidden binary incompatibilty between different curl flavours. raising severity to important, since this makes package unusable for any environment secured by user certificates. BTW, centos and SuSE does not show this bug. Maybe the bug has to be fixed in libcurl4-gnutls itself--- git-2.1.4/debian/control 2014-12-20 03:13:38.000000000 +0100 +++ control 2015-10-28 17:55:35.679424672 +0100 @@ -4,7 +4,7 @@ Maintainer: Gerrit Pape <pape@smarden.org> Uploaders: Jonathan Nieder <jrnieder@gmail.com> Build-Depends: libz-dev, libpcre3-dev, gettext, - libcurl4-gnutls-dev, libexpat1-dev, + libcurl4-openssl-dev, libexpat1-dev, subversion, libsvn-perl, libyaml-perl, tcl, libhttp-date-perl | libtime-modules-perl,