server certificate verification failed

[Ashley Williams <as...@db.com>]

Hi,

After a couple of weeks of successful builds, we are suddenly getting the 
following error in continuum 1.0.3:

svn: PROPFIND of '/svn/ges-abfo/trunk': Server certificate verification 
failed: issuer is not trusted (https://ges-abfo.ibitdev.com)

Has anyone seen anything like this before? One guess is that the ssl 
certificate has somehow changed and if so, is there some way to get 
continuum to auto-accept this?

Thanks
- Ashley

---

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.

Re: server certificate verification failed (sorry, offtopic)

[Graham Leggett <mi...@sharp.fm>]

On Mon, October 15, 2007 3:54 pm, Ashley Williams wrote:

> 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.

I would seriously doubt that a company that offers commercial svn hosting
would expect customers to accept a self signed certificate. It would pay
to query them and check, they may only supply you with the root
certificate if you ask for it.

Regards,
Graham
--

Re: server certificate verification failed (sorry, offtopic)

[Ashley Williams <as...@db.com>]

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" <mi...@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.

Re: server certificate verification failed

[Graham Leggett <mi...@sharp.fm>]

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
--

Re: server certificate verification failed

[Ashley Williams <as...@db.com>]

See comments inline...

"Graham Leggett" <mi...@sharp.fm> wrote on 15/10/2007 13:40:36:

> On Mon, October 15, 2007 1:51 pm, Ashley Williams wrote:
> 
> > I would expect that if I have taken the decision to connect to a
> > repository for development then it would go without saying that I also
> > trust that site.
> 
> You are missing the point behind SSL.

Quite possibly!

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.

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. 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.


> 
> Obviously you trust the site, you put it there, but how does your
> continuum know that the site it is connecting to is the site you trust?
> Diverting continuum to connect to something else is not very difficult 
to
> do at all by a third party device on the same LAN (even a switched LAN),
> it is not difficult to fool your subversion client to try and log into a
> fake repository using the correct credentials. Having done this, the
> attacker has a known working username and password for your repo, and
> depending on how you set it up, they could either steal code or alter 
code
> to their advantage.
> 
> (Luckily as you run svn over https, you are not open to the risk of a
> disgruntled employee deleting the files behind your CVS repo, as 
happened
> at a friend's company a few weeks ago causing much angst and grief).
> 
> 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.

Re: server certificate verification failed

[Graham Leggett <mi...@sharp.fm>]

On Mon, October 15, 2007 1:51 pm, Ashley Williams wrote:

> I would expect that if I have taken the decision to connect to a
> repository for development then it would go without saying that I also
> trust that site.

You are missing the point behind SSL.

Obviously you trust the site, you put it there, but how does your
continuum know that the site it is connecting to is the site you trust?
Diverting continuum to connect to something else is not very difficult to
do at all by a third party device on the same LAN (even a switched LAN),
it is not difficult to fool your subversion client to try and log into a
fake repository using the correct credentials. Having done this, the
attacker has a known working username and password for your repo, and
depending on how you set it up, they could either steal code or alter code
to their advantage.

(Luckily as you run svn over https, you are not open to the risk of a
disgruntled employee deleting the files behind your CVS repo, as happened
at a friend's company a few weeks ago causing much angst and grief).

Regards,
Graham
--

Re: server certificate verification failed

[Ashley Williams <as...@db.com>]

I would expect that if I have taken the decision to connect to a 
repository for development then it would go without saying that I also 
trust that site.
I'm not suggesting also that continuum auto-trusts out of the box, but 
rather as a configurable property and maybe against certain certificates.

However I take your point that this is a subversion config issue - looks 
like I'll be browsing the redbook for the next half an hour ;)

Thanks
- Ashley

"Graham Leggett" <mi...@sharp.fm> wrote on 15/10/2007 10:37:38:

> On Mon, October 15, 2007 10:57 am, Ashley Williams wrote:
> 
> > Ok I can do this. I was hoping that since continuum is responsible for
> > calling out to subversion, it could automatically accept on my behalf.
> > After all I've already told continuum of my user name and password for 
the
> > repository url so it should have everything it needs to do this.
> 
> The trouble with this is that by doing this, you are removing most of 
the
> protection the SSL certificate is offering you.
> 
> Subversion can be configured to trust a root CA certificate(s), which 
will
> mean in theory that subversion will always trust any new certs it finds,
> on condition those certs are signed by a trusted root CA. This should 
make
> your problem go away.
> 
> 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.

Re: server certificate verification failed

[Graham Leggett <mi...@sharp.fm>]

On Mon, October 15, 2007 10:57 am, Ashley Williams wrote:

> Ok I can do this. I was hoping that since continuum is responsible for
> calling out to subversion, it could automatically accept on my behalf.
> After all I've already told continuum of my user name and password for the
> repository url so it should have everything it needs to do this.

The trouble with this is that by doing this, you are removing most of the
protection the SSL certificate is offering you.

Subversion can be configured to trust a root CA certificate(s), which will
mean in theory that subversion will always trust any new certs it finds,
on condition those certs are signed by a trusted root CA. This should make
your problem go away.

Regards,
Graham
--

Re: server certificate verification failed

[Ashley Williams <as...@db.com>]

Ok I can do this. I was hoping that since continuum is responsible for 
calling out to subversion, it could automatically accept on my behalf. 
After all I've already told continuum of my user name and password for the 
repository url so it should have everything it needs to do this.

Many thanks
- Ashley

Emmanuel Venisse <em...@venisse.net> wrote on 15/10/2007 09:39:06:

> Continuum can't accept it automatically because it's svn that must 
accept it.
> On your continuum server, run svn with the user that run continuum 
> to accept permanently the certificate.
> 
> Emmanuel
> 
> Ashley Williams a écrit :
> > Hi,
> > 
> > After a couple of weeks of successful builds, we are suddenly getting 
the 
> > following error in continuum 1.0.3:
> > 
> > svn: PROPFIND of '/svn/ges-abfo/trunk': Server certificate 
verification 
> > failed: issuer is not trusted (https://ges-abfo.ibitdev.com)
> > 
> > Has anyone seen anything like this before? One guess is that the ssl 
> > certificate has somehow changed and if so, is there some way to get 
> > continuum to auto-accept this?
> > 
> > Thanks
> > - Ashley
> > 
> > ---
> > 
> > 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.
> 


---

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.

Re: server certificate verification failed

[Emmanuel Venisse <em...@venisse.net>]

Continuum can't accept it automatically because it's svn that must accept it.
On your continuum server, run svn with the user that run continuum to accept permanently the certificate.

Emmanuel

Ashley Williams a écrit :
> Hi,
> 
> After a couple of weeks of successful builds, we are suddenly getting the 
> following error in continuum 1.0.3:
> 
> svn: PROPFIND of '/svn/ges-abfo/trunk': Server certificate verification 
> failed: issuer is not trusted (https://ges-abfo.ibitdev.com)
> 
> Has anyone seen anything like this before? One guess is that the ssl 
> certificate has somehow changed and if so, is there some way to get 
> continuum to auto-accept this?
> 
> Thanks
> - Ashley
> 
> ---
> 
> 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.