Discussion:
SSL Certificate issuer not recognized.
Stratis Karamanlakis
2005-03-31 08:52:02 UTC
Permalink
Hello,

I am running svnserver using apache and WebDAV using HTTPS.

When TortoiseSVN tries to access my server, I get the warning:

Error validating server certificate for https://secure.odesk.com:443
Unknown certificate issuer:
Fingerprint: ca:a1:ba:7f:37:...
Distinguished name: ....
Do you want to proceed ?

The certificate I have installed is a wildcard certifcate (*.odesk.com)
issued by an intermediate CA , Comodo:
CN = Comodo Class 3 Security Services CA
OU = (c)2002 Comodo Limited
OU = Terms and Conditions of use: http://www.comodo.net/repository
OU = Comodo Trust Network
O = Comodo Limited
C = GB
whose Root CA is GTE CyberTrust Global Root
CN = GTE CyberTrust Global Root
OU = GTE CyberTrust Solutions, Inc.
O = GTE Corporation
C = US

The particular wildcard certificate is accepted by IE, Firefox etc.

Can you please provide any feedback on where the error lies ?
+ Are there any known issues with wildcard certificate chains and
TortoiseSVN?
+ Is the Root CA above 'unknown' to TortoiseSVN or OpenSSL or whatever...
In that case is it likely that it could be added sometime soon ?

--
thanks
Stratis Karamanlakis
Markus Schuh
2005-03-31 10:04:40 UTC
Permalink
Post by Stratis Karamanlakis
Error validating server certificate for https://secure.odesk.com:443
[...]
Post by Stratis Karamanlakis
Can you please provide any feedback on where the error lies ?
+ Are there any known issues with wildcard certificate chains and
TortoiseSVN?
+ Is the Root CA above 'unknown' to TortoiseSVN or OpenSSL or
whatever...
In that case is it likely that it could be added sometime soon ?
When connecting to a https URL TortoiseSVN uses the subversion library
which uses neon to connect to the URL. The ssl-work in neon (like
certificate validation) is handled by the ssl-libraries "libeay32.dll"
and "ssleay32.dll" (Included in tsvn msi installation.)

So:

Isn't it possible to "accept permanently" once for every user
(because of an error) or do you just want this question to
never appear after tsvn installation?

In the first case you should ask your question on openssl
mailing lists.

In the second case you could give the following a try:
(never tried this setup exactly under Windows, so don't except too much.)

The included precompiled libraries probably search the "cert bundle"
under %HOMEPATH%\usr\local\ssl\cert.pem (found with FileMon)
or %SSL_CERT_FILE% if set.

You should export the root certificates which you want tsvn
o trust and give the ssl routines used in tsvn the information
where to look. (system environment variable)

For infos about root certificates and openssl see
http://lynx.isc.org/current/README.rootcerts
--
***@sdm.de
Jesse
2005-03-31 13:42:41 UTC
Permalink
We seemingly randomly get an error from tortoise...

"The REPORT request returned invalid XML in response..."

After many many attempts at deleting /cleanup/switching/ eventually we found
that editing the entries file and removing the incomplete=true from the XML
made tortoise work again, restoring us to that illustrious productive state
once again. This clearly cannot be sanctioned procedure, and despite the
satisfaction that comes with solving such an irritating problem, is there a
more robust answer? Is there a way to prevent tortoise from presenting these
random warnings? Is there an automated way to fix this issue?

Jesse LaChapelle
Simon Large
2005-03-31 13:59:25 UTC
Permalink
Post by Jesse
We seemingly randomly get an error from tortoise...
"The REPORT request returned invalid XML in response..."
After many many attempts at deleting /cleanup/switching/ eventually
we found that editing the entries file and removing the
incomplete=true from the XML made tortoise work again, restoring us
to that illustrious productive state once again. This clearly cannot
be sanctioned procedure, and despite the satisfaction that comes with
solving such an irritating problem, is there a more robust answer? Is
there a way to prevent tortoise from presenting these random
warnings? Is there an automated way to fix this issue?
TortoiseSVN does not touch the entries file directly. It uses the
subversion libraries, so you need to ask that question on the subversion
mailing list. If you have a way of reproducing this problem (apart from
deliberately corrupting the entries file) they will be interested to see
it.

Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
Jesse
2005-03-31 15:48:58 UTC
Permalink
Thank you for the timely response.

Seems then that I may have found a case where tortoise doesn't interoperate
correctly with Subversion. This failure on tortoise's part to properly parse
the subversion generated 'entries' file should likely be added as a bug.
Where can I do that?

Jesse


----- Original Message -----
From: "Simon Large" <***@slarge.plus.com>
To: <***@tortoisesvn.tigris.org>
Sent: Thursday, March 31, 2005 8:59 AM
Subject: Re: [TSVN] XML Parse error
Post by Simon Large
Post by Jesse
We seemingly randomly get an error from tortoise...
"The REPORT request returned invalid XML in response..."
After many many attempts at deleting /cleanup/switching/ eventually
we found that editing the entries file and removing the
incomplete=true from the XML made tortoise work again, restoring us
to that illustrious productive state once again. This clearly cannot
be sanctioned procedure, and despite the satisfaction that comes with
solving such an irritating problem, is there a more robust answer? Is
there a way to prevent tortoise from presenting these random
warnings? Is there an automated way to fix this issue?
TortoiseSVN does not touch the entries file directly. It uses the
subversion libraries, so you need to ask that question on the subversion
mailing list. If you have a way of reproducing this problem (apart from
deliberately corrupting the entries file) they will be interested to see
it.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
Rainer Müller
2005-03-31 16:01:05 UTC
Permalink
Post by Jesse
Thank you for the timely response.
Seems then that I may have found a case where tortoise doesn't
interoperate correctly with Subversion. This failure on tortoise's part
to properly parse the subversion generated 'entries' file should likely
be added as a bug. Where can I do that?
As Simon said, TortoiseSVN does not do anything to the entries file
itself. It uses the Subversion libraries which do all the things to your
WC. Please report this to their mailing list and maybe also try to
reproduce it with the command line client.

Rainer
SteveKing
2005-03-31 16:42:11 UTC
Permalink
Post by Stratis Karamanlakis
I am running svnserver using apache and WebDAV using HTTPS.
Error validating server certificate for https://secure.odesk.com:443
Fingerprint: ca:a1:ba:7f:37:...
Distinguished name: ....
Do you want to proceed ?
The certificate I have installed is a wildcard certifcate (*.odesk.com)
[snip]
Post by Stratis Karamanlakis
The particular wildcard certificate is accepted by IE, Firefox etc.
Can you please provide any feedback on where the error lies ?
+ Are there any known issues with wildcard certificate chains and
TortoiseSVN?
Not that I know of.
Post by Stratis Karamanlakis
+ Is the Root CA above 'unknown' to TortoiseSVN or OpenSSL or whatever...
In that case is it likely that it could be added sometime soon ?
Got to %APPDATA%\Subversion (usually c:\documents and
settings\yourusername\appdata). There you'll find a file called
"servers" in the Subversion folder. Open it with e.g. notepad.
Then, read all the comments in that file to find out how you can set up
your certificate with Subversion (hint: ssl-authority-files).

Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
Continue reading on narkive:
Loading...