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" <[EMAIL PROTECTED]> 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.
