Using SourceTree on a local apache server, the certificate is getting rejected despite being accepted in the keychain.

[Dallas Hockley]

I have a local self-hosted Mercurial repository that has run fine with MacHg over https for quite some time. Now I'm getting an error trying to use SourceTree to access it when I attempt to push to it. The output is:

hg push --new-branch default

pushing to https://username:***@[URL REMOVED]:8080/hg/projectname

abort: error: _ssl.c:499: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Completed with errors, see above

The certificate has been accepted into the keychain via Safari on Mac OS X but this keeps showing up in SourceTree. Is there a way I can get these self-signed certificates to be accepted on repositories that need them?

[Dallas Hockley · Accepted solution]

Ok, after much mucking about, it seems MacHg had a fingerprint line in the Application Support directory that it can get to from Preferences. I regenerated all the keys on the server as self-signed to try to track this all down.

The keychain defaulting is not working. None of the references I found nor the one listed seemed to use the accepted key in the keychain regardless of the dummy file being present and configured or not for SourceTree. So I tossed that avenue after many key regens and many configuration tweaks and restarts.

What DID work is this: Adding the fingerprint into the .hgrc file. I got the idea from the MacHg support site here:

http://machghelp.jasonfharris.com/kb/connections/how-do-i-add-a-server-certificate-or-fingerprint-for-https

and then proceeded to add a fingerprint to the .hgrc file for SourceTree in ~ resembling (real info removed to protect the innocent)

[hostfingerprints]

myhost.mydomain.org=43:ee:eb:43:9b:42:aa:34:66:f5:21:cc:76:d4:22:7d:16:52:ee:98

Now BOTH of the clients are working correctly and no longer arguing about the certificate that has been self-signed, fingerprinted, and submitted to the DHS pre-flight screening.

The only thing I'd add is that MacHg, in this one case, was actually easier to use and configure. Which should never be the case in my opinion. Seems like a small thing to deal with for SourceTree to allow the fingerprints to be imported on approval by the user so that development and internal servers can more easily be used as well as local mirror servers and staging servers etc.

Thanks for the help though Steve as it did get me thinking along the correct lines. Still don't know why the keychain isn't getting pulled in.

[stevestreeting]

Thanks for the update, I'm glad you figured it out (removed my previous comment as it's now defunct). I'll try to make this a bit smoother in future!

[stevestreeting]

Have you already specified the web.cacerts option in your ~/.hgrc?

In Mercurial, the web.cacerts option controls acceptance of self-signed certs, more information is available here: http://mercurial.selenic.com/wiki/CACertificates#Mac_OS_X_10.6_and_higher

By default, if you haven't specified web.cacerts in your .hgrc already, SourceTree uses a dummy file as suggested in the article above so that trusts set up in your Keychain will be picked up. However, if you have web.cacerts specified already then SourceTree doesn't change anything.

Please check that article above and check your configuration, you should be able to get it to pick up your keychain trusts based on that.

[Dallas Hockley]

I checked the .hgrc file, and it had a lot of sourcetree option in there, but the [web] cacerts=.... wasn't in there. I generated one as specified in teh link you posted and added that in. Then quit and restarted SourceTree but I'm getting exactly the same behaviour. Your post indicates that if that option isn't there then SourceTree mocks it up and pulls the keychain as well, but that also isn't working. I'm running on Mac OS X Lion, not 10.6. The cert generation required a minimum 4 character passphrase, which is slightly different from the "just press return" on all the prompts, so it may be a different version of things on Lion? It's interesting that MacHg is working without issue, and now the SourceTree indicates that there is a rev to be pushed, but that was pushed by MacHg already, so I'm wondering if it can't query the remote at all now? I'm really puzzled as to what info it does have from the remote and when it retrieved that. I had a trial version that was quite old of SourceTree that I replaced with the newest. I'm not sure if that would have confused the settings?

[Dallas Hockley]

Further to this I wiped the .hgrc file in my home directory and started up SourceTree again, but still no change in behaviour. It rewrote the file but still isn't respecting the keychain.

[stevestreeting]

The reason MacHg works is that it disables all SSL checks, which really isn't the correct thing to do, but of course it avoids the problem rather more simply. Mercurial introduced the SSL cert checking a few versions ago and they really expect you to use it, so I deliberately didn't take this route. Yes, SourceTree won't be able to access your remote at all if the SSL cert is being rejected by Mercurial.

I've had this issue raised before and the steps above have resolved it for everyone else so far, so I'm wondering if the cert really is properly trusted in your keychain. Are you absolutely sure that it is?

The web.cacerts option is set at runtime (not in the .hgrc) by SourceTree to make hg use the keychain, but it's still worth setting it in your .hgrc too because if you ever wanted to use the command-line, you wouldn't be able to otherwise.

[mac mac]

Hi,

I'm having a simulair problem, but with Git and a StartSSL certificate.

CLI hg and git don't have any issues connecting to my server, but SourceTree does. As far as I know the StartSSL root-certificate is accepted by MacOS.

The solution above (adding the fingerprint of my server to .hgrc) works, but I didn't find a solution like this for Git.