Cannot pull/push to https server with self-signed certificate

[Brian Sullivan]

On Thu, Jan 6, 2011 at 10:15 PM, Steve Borho <steve at borho.org> wrote:

> On Thu, Jan 6, 2011 at 10:11 PM, Brian Sullivan <bmsullivan at gmail.com>
> wrote:
> > On Thu, Jan 6, 2011 at 9:45 PM, Steve Borho <steve at borho.org> wrote:
> >>
> >> On Thu, Jan 6, 2011 at 8:43 PM, Brian Sullivan <bmsullivan at gmail.com>
> >> wrote:
> >> > Mads,
> >> > Thanks for the response!
> >> > After reading your message, I performed the steps exactly as described
> >> > on
> >> > the Mercurial wiki page you linked to.  I navigated to our repo site
> in
> >> > Firefox and exported the certificate at the root of the hierarchy
> (there
> >> > was
> >> > actually only one in the tree).  Once exported, I got the hash on my
> Mac
> >> > using openssl and copied that into the cacert.pem file on my Windows
> VM.
> >> >  This still results in the same error when trying to perform a remote
> >> > operation.
> >> > Could this have something to do with line endings, since I'm copying
> the
> >> > hash text from a Mac terminal window into my Windows text editor
> (GVim)?
> >> >  To
> >> > address that possibility, I joined the whole hash onto one line and
> >> > entered
> >> > the carriage returns manually, but it didn't seem to have any effect.
> >> >  GVim
> >> > says the file is [unix], is that what it should be, even on a Windows
> >> > system?  I'm grasping at straws, here.
> >>
> >> I don't believe line endings have any effect one way or another.  gvim
> >> can convert from dos to unix using the ':set ff=dos' and ':set
> >> ff=unix' commands, fwiw.
> >>
> >> > I really appreciate your help.  And I also appreciate the security
> >> > concerns
> >> > of the Mercurial developers, and think they made the right decision
> for
> >> > the
> >> > long run.  I just hope the usability around using self-signed certs
> gets
> >> > a
> >> > bit easier; I think some of my coworkers might have a difficult time
> >> > with
> >> > this, even if I explained the steps to them.  Keep in mind, these are
> >> > guys
> >> > who would have used TFS if I hadn't convinced them otherwise. ;-)
> >> > Brian
> >>
> >> Are you sure the server certificate is self-signed.  I've discovered
> >> that some servers that are virtual hosted will depend on SNI [1] to
> >> learn of the proper server hostname to validate against, and Python
> >> 2.6 (the basis of Mercurial Windows installers) does not support SNI
> >> for SSL connections.  This feature was just recently added to Python
> >> 3.2, and Mercurial itself does not support Python 3 (nor does
> >> TortoiseHg for that matter).  hg.assembla.com seems to fall into this
> >> category.
> >>
> >> Beyond SNI, there could be other reasons for server validation failure
> >> (certificate is out of date, invalid host names, no known valid CA),
> >> and they are all unhelpfully lumped together into a single error
> >> message from the openssl library.
> >>
> >> As mentioned in the docs, you _can_ connect to the server by setting
> >> [web] cacerts= in your user Mercurial.ini file.  You will get warnings
> >> during pushes saying that the server was not validated, but it will at
> >> least work.
> >>
> >> [1] http://en.wikipedia.org/wiki/Server_Name_Indication
> >>
> >> --
> >> Steve Borho
> >
> >
> > Steve,
> > The certificate we used was created using the "Create Self-Signed
> > Certificate" option in IIS under "Server Certificates", and it has an
> > expiration date of 10/4/2011.  The server itself is a physical machine
> > on-premises here, not a virtual-hosted instance.  Would that mean it's
> > unlikely that the problem is caused by SNI?
> > Prompted by the message when viewing the certification window, I
> installed
> > the certificate into the Trusted Root Certification Authorities store,
> but
> > this also had no effect.
> > I'm beginning to think that I may just have to deal with the warning
> > messages, at least for now, unless you all have any other ideas.
>
> If you have access to openssl, can you try this?
>
> openssl s_client -connect hostname:443 -CAfile /path/to/my/cacert.pem
> (hit ctrl-c to cancel)
>
> it should dump the server's certificate to stdout in a format that's
> copy/pasteable.
>
> Alternatively, you can do the same from a Python interpreter shell with:
>
> import ssl
> print ssl.get_server_certificate(('hostname', 443))
>
> --
> Steve Borho
>

Steve,

I tried both of those, which resulted in the same string I had pasted into
my cacert.pem file previously.  I did notice that I received the following
message as a part of the output of the openssl call:

---
No client certificate CA names sent
---

Could that be the problem?  Would that mean there's no key I could put into
my cacert.pem file that would make it work because the server isn't
specifying a CA? I'm sure my ignorance of how certificates work is showing
here, and I apologize.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110106/c9677572/attachment.htm>