SSL works with browser, wget, and curl, but fails with git

I have a website I am using to host redmine and several git repositories

This works perfectly for http, but I can't clone with https, i.e.

git clone http://mysite.com/git/test.git

works fine, but

git clone https://mysite.com/git/test.git

fails

The strange thing is that https seems to work for everything else I have tested. If I open

https://mysite.com/git/test.git

in a browser (tested in chrome and firefox), I get no errors or warnings. I can also

curl https://mysite.com/git/test.git
wget https://mysite.com/git/test.git

both of which work with no complaints or warnings.

Here is the verbose output from git:

$ GIT_CURL_VERBOSE=1 git clone https://user@mysite.com/test/test.git
Cloning into test...
Password:
* Couldn't find host mysite.com in the .netrc file; using defaults
* About to connect() to mysite.com port 443 (#0)
*   Trying 127.0.0.1... * Connected to mysite.com (127.0.0.1) port 443 (#0)
* found 157 certificates in /etc/ssl/certs/ca-certificates.crt
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection #0
* Couldn't find host mysite.com in the .netrc file; using defaults
* About to connect() to mysite.com port 443 (#0)
*   Trying 127.0.0.1... * Connected to mysite.com (127.0.0.1) port 443 (#0)
* found 157 certificates in /etc/ssl/certs/ca-certificates.crt
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection #0
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://user\
@mysite.com/test/test.git/info/refs

fatal: HTTP request failed

Here is the verbose output from curl, with the personal info changed:

* About to connect() to mysite.com port 443 (#0)
*   Trying 127.0.0.1... connected
* Connected to mysite.com (127.0.0.1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*        subject: C=US; <... cut my certs info ...>
*        start date: 2011-10-18 00:00:00 GMT
*        expire date: 2013-10-17 23:59:59 GMT
*        subjectAltName: mysite.com matched
*        issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO High-Assurance Secure Server CA
*        SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3
> Host: mysite.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 18 Oct 2011 21:39:54 GMT
< Server: Apache/2.2.14 (Ubuntu)
< Last-Modified: Fri, 14 Oct 2011 03:20:01 GMT
< ETag: "8209c-87-4af39bb89ccac"
< Accept-Ranges: bytes
< Content-Length: 135
< Vary: Accept-Encoding
< Content-Type: text/html
< X-Pad: avoid browser bug
<
<p>Welcome to the mysite.com<p/>
* Connection #0 to host mysite.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

The only difference I can see is that git seems to be using an explicit CAfile while curl uses the whole directory? I'm new to ssl (at least on the admin side), so I'm not sure what this means or how I could configure git to work the same way as curl.

I am using git 1.7.5.4 and apache 2.2.14 on Ubuntu 10.04. I've tried cloning from 3 different linux hosts (including another account on the server itself), and nothing works.

I've also used the openssl tool to verify my cert on the server:

$openssl verify -purpose sslserver -CAfile chain.crt signed.pem 
signed.pem: OK

This may be related to the bug https://bugs.maemo.org/show_bug.cgi?id=4953 but it seems different because I am not getting any warning or errors in any other program.

It may be worth mentioning that I am using gitolite and redmine_git_hosting using smart http to do authentication over https. I don't think any of this is at fault though, because the problem exists even if I just stick an otherwise working bare repo in /var/www and access it directly. Also, git over ssh (with and without gitolite) works.

Please let me know if you have any idea what might be wrong or if you'd like some more info. I'd really prefer to get ssl working properly, as opposed to forcing everyone to disable certificate checking in git, although that is a current workaround.

Thanks for reading this long post!

It turns out that this was a gnuTLS issue. gnuTLS is order sensitive, while openssl is not. I re-ordered the certificates in my intermediate cert file and the problem went away

XCondE's answer will address the problem, but turning off security warnings always feels like a bad idea. If you're running on an ubuntu box, then the issue may be that the CA certificate for your web server isn't in the /etc/ssl/certs/ca-certificates.crt file. I ran into this with a git server hosted on a web server with a SSL certificate signed by www.incommon.org.

You can add the intermediate certificate to your ca-certificates file, as follows:

wget http://cert.incommon.org/InCommonServerCA.crt
openssl x509 -inform DER -in InCommonServerCA.crt -out incommon.pem
cat /etc/ssl/certs/ca-certificates.crt incommon.pem > ca-certs2.crt
sudo cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.bak
sudo cp ca-certs2.crt /etc/ssl/certs/ca-certificates.crt

There's a good discussion of what's going on behind the scenes here: http://curl.haxx.se/docs/sslcerts.html

I encountered this error with one of my Comodo PositiveSSL certificates and was able to fix it by changing the order of the intermediate certificates.

After ordering the certificate, I was provided with the following files:

Root CA Certificate - AddTrustExternalCARoot.crt
Intermediate CA Certificate - COMODORSAAddTrustCA.crt
Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt
PositiveSSL Wildcard Certificate - STAR_mydomain_com.crt

Originally, the order of certificates in the .crt I was providing to Nginx was as follows:

PositiveSSL Wildcard Certificate - STAR_mydomain_com.crt
Intermediate CA Certificate - COMODORSAAddTrustCA.crt
Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt

However, I reversed the order of the last two certificates and Git no longer throws verification errors.

git uses gnutls for this stuff, which requires the CA be specified. This can be done with per-respository with:

git config http.sslcapath <path to CA directory>

git config http.sslcainfo <path to CA cert>

You can also specify --system or --global.

export GIT_SSL_NO_VERIFY=1

From http://blog.breadncup.com/2011/06/09/skip-git-ssl-verification/

WARNING: as some people mentioned, this disables verification, leaving you open to a sleuth of security issues. You shouldn't rely on it long-term but, in a pinch, it will get the job done.

The problem may be that you didn't configure correctly Apache

You may have to add your server name to the Apache configuration file /etc/apache2/sites-enabled/default-ssl.conf, e.g.: