I wonder if we are talking at cross purposes. Our subversion repository is
actually hosted with
a thirdparty (collabnet) and I believe they have changed their certificate
and to one that isn't trusted
by a root certificate. Therefore unless I am missing yet another point, I
don't believe we can
have any influence over this.
If our repository was inhouse, then what you are are saying would make
sense to me.
"Graham Leggett" <minfrin@sharp.fm> wrote on 15/10/2007 14:26:02:
> On Mon, October 15, 2007 3:08 pm, Ashley Williams wrote:
>
> > Although I would have thought the issue of whether or not
> > I trust a particular site is different from whether my continuum
> > installation is connecting
> > me to the site I think it should be.
>
> SSL performs two functions - one to obscure the data in transit to
protect
> from eavesdropping, the second to ensure that you are talking to the
right
> party so that you don't end up giving away secrets to imposters.
>
> > So can you give guidance as to what my action should be? Each
developer
> > has
> > just been hitting the 'accept permanently' button in subclipse in
their
> > own
> > workspaces.
>
> Ideally you need to deploy a certificate onto your server that is
trusted
> by a root certificate. The root certificate gets installed on all your
> clients in some kind of trusted fashion. When the svn client connects to
> the svn server, it says "Oh, you gave me a cert, is this cert signed by
> one of the root certs I have locally trusted? Yes? Come on right in".
>
> When your developers are trained to just hit "p", what they are
> effectively doing is saying "trust anybody, even disgruntled employee's
> fake server three cubicles down".
>
> The quickest way to get a certificate that's trusted by a root
certificate
> is to buy one from a certificate authority. You don't need to buy a
> certificate with onerous identity checking, because you trust yourself
> already.
>
> A cheaper alternative is to create a root certificate yourself using a
> toolkit like openssl. Don't create a self signed cert, as it doesn't
offer
> you the same protection.
>
> > So should we be thoroughly investigating the proposed
> > certificate before doing
> > this, since a glance at the certificate hostname field looks fine to
me (
> > *.ibitdev.com).
> > Continuum is in a dmz and has not been reconfigured since
> > the last build, so I am fairly certain it is connecting to the correct
> > url.
>
> The only way continuum can be sure the correct URL is being used is if
the
> certificate presented is trusted by a CA certificate on svn (via
> continuum)'s list of trusted CA certificates.
>
> If continuum breaks expecting a "p", it means something weird or dogy is
> going on on your network, which warrants investigation.
>
> Regards,
> Graham
> --
>
>
---
This e-mail may contain confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender immediately and
delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate
and regulatory disclosures.