Created attachment 836826 [details] use openssl defaults if smtpsslcertpath is not specified Description of problem: I use gmail for sending patches. If I have the following defined in my ~/.gitconfig: [sendemail] smtpencryption = tls smtpserver = smtp.gmail.com smtpuser = ruben smtpserverport = 587 and try to send a patch, this fails with: STARTTLS failed! SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/libexec/git-core/git-send-email line 1236. Version-Release number of selected component (if applicable): [ruben@vm ~]$ rpm -q git-email git-email-1.8.4.2-2.fc21.noarch Additional info: I traced this down to ssl_verify_params() in /usr/libexec/git-core/git-send-email, which sets the SSL_ca_path to /etc/ssl/certs. If SSL_ca_path is not specified, IO::Socket::SSL uses the openssl defaults, which use the right bundle on Fedora. Patch attached.
I've been bitten by this too
Thanks for the report and patch Ruben. If anyone affected by this issue has some time, this would be great to take upstream and work it out in a way that is acceptable for everyone. I haven't used git send-email in ages personally, so I've never hit this one.
I'm seeing the same problem with git-email-1.8.4.2-1.fc20.noarch After a little bit of digging I found out that the problem is in the way git-send-email (and IO-Socket-SSL) handles directories. It looks like it does not recognize ca-bundle.crt as a certificate location. If I set my git config: smtpsslcertpath = /etc/ssl/certs using ssl enabled smtp fails (tested on gmail). However, setting it to: smtpsslcertpath = /etc/ssl/certs/ca-bundle.trust.crt fixes the problem. The problem can also be fixed by adding simlinks to /etc/certs/ directory: Equifax_Secure_CA.pem -> ca-bundle.crt 578d5c04.0 -> Equifax_Secure_CA.pem or just 578d5c04.0 -> ca-bundle.crt Equifax and the hash value are for gmail. I'm not sure whether supporting ca-bundle is the job for fedora or upstream.
Comment on attachment 836826 [details] use openssl defaults if smtpsslcertpath is not specified Tested-by: Igor Gnatenko <i.gnatenko.brain>
Chris, apply patch please ;)
Igor, thanks for testing. I do think that we want to get this pushed upstream rather than as a patch to our build. At the least, if the defaults from upstream aren't working in Fedora, we should ensure that the defaults can be configured at build time. Hopefully someone that has the itch to see this fixed can help move that process along. I've been kept too busy with other areas to try and drive this, but perhaps someone else can find the time and motivation for it. Chris is likely busy with other tasks these days, too.
(In reply to Todd Zullinger from comment #6) > Igor, thanks for testing. I do think that we want to get this pushed > upstream rather than as a patch to our build. At the least, if the defaults > from upstream aren't working in Fedora, we should ensure that the defaults > can be configured at build time. Hopefully someone that has the itch to see > this fixed can help move that process along. > > I've been kept too busy with other areas to try and drive this, but perhaps > someone else can find the time and motivation for it. Chris is likely busy > with other tasks these days, too. No problem ;) Sent to upstream[0].. [0]http://thread.gmane.org/gmane.comp.version-control.git/240472
Excellent! Thanks!
Sorry all for my late reply. I haven't had much time to dive into this either. I was in a hurry and quickly cooked up a patch, which can be seen more as a workaround than as a proper fix, let alone as something which is ready for upstream inclusion. I was able to spend a few more minutes tonight, and it turns out this is even more tricky than I thought: git send-email passes /etc/ssl/certs as SSL_ca_path to IO::Socket::SSL, but IO::Socket::SSL doesn't think this is a proper ssl directory. What my patch does is let it fall back to the default, which is /etc/pki/tls/cert.pem So IMHO the issue is either within IO::Socket::SSL, the underlying IO::Net::SSLeay, openssl or the layout of the /etc/ssl/certs directory on Fedora. Turtles all the way down...
Ok, so IO::Socket::SSL calls Net::SSLeay::CTX_load_verify_locations( $ctx, $arg_hash->{SSL_ca_file} || '',$arg_hash->{SSL_ca_path} || '') Net:SSLeay is a wrapper around OpenSSL, so this calls openssl's SSL_CTX_load_verify_locations (http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html) The comments for that function say: If CApath is not NULL, it points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name hash value exist, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the ordering of the extension number, regardless of other properties of the certificates. Use the c_rehash utility to create the necessary links. So Jan was right in comment #3, and the directory passed to openssl is not in a format it understands. OpenSSL does however understand /etc/pki/tls/cert.pem as CAfile, which is what my patch accomplishes. So in a sense this is still a bug in git, at least on Fedora, since it passes on the wrong directory. We're discussing this upstream and hopefully we'll have a solution soon. There's of course the issue of /etc/ssl/certs not being in the right format, but if I find the time I'll report a bug against ca-certificates.
Fixed in 1.9.0.