Thanks for this problem description and resolution. I was using an older
version of TSVN and was asked (told) to upgrade to the latest. Now I
can't even log into the server. From the description below, I think I
have the same problem. :-(
I will take this up with the server admionistrator, as he is the one who
told me to upgrade my TSVN copy. I used TSVN a little bit a year ago, but
other than that, all my SVN use has been cle from Linux.
> Thanks for your help Stefan.
>
> I tried your suggestions (using the 1.6.11 svn CLI on windows and
> specifying the --non-interactive --trust-server-cert options), but
> neither worked.
>
> Fortunately, when I tried the latest svn CLI (1.6.15), it functioned
> just like the linux CLI (asking me to accept the certificate validation
> error) and then the operation succeeded.
>
> The problem still exists in the latest version of TortoiseSVN (which
> claims to be linked against svn 1.6.15), but I will take that up w/ the
> TortoiseSVN folks.
>
> Thanks again!
>
> Nick
>
>
> On Thu, 2010-12-16 at 19:17 +0100, Stefan Sperling wrote:
>
>> On Thu, Dec 16, 2010 at 09:34:05AM -0500, Nick wrote:
>> > Hi all,
>> >
>> > At some point in the last year I stopped being able to access my SVN
>> > repository remotely via https using the SVN CLI and TortoiseSVN on
>> > Windows. Unfortunately since I hadn't used svn on my windows machine
>> > for a long time (many months), I cannot give a more accurate
>> timeframe.
>> >
>> > The error I get when I try to checkout via the svn.exe CLI is (I
>> masked
>> > my domain & path):
>> >
>> > c:\ svn.exe checkout https://.com/
>> > svn: OPTIONS of 'https://.com/':
>> > SSL negotiation failed: SSL error code -1/1/336032856
>> > (https://.com)
>> >
>> > My svn server is running via Apache. Client and server are both
>> version
>> > is 1.6.13. The web server is using openssl 1.0.0c.
>> >
>> > I am able to checkout and access my repository fine from another linux
>> > client via the same domain name. And on Windows, I can browse the
>> > repository with Firefox. But in both of these cases, the linux svn
>> CLI
>> > and Firefox both prompt that the SSL certificate is risky/invalid for
>> a
>> > couple reasons: it's self-signed and reflects a different host than
>> the
>> > domain I'm actually connecting to. This is because the SSL
>> certificate
>> > reflects my server's internal hostname (for reasons I won't get into
>> > here) rather than the public domain name. So for both the linux
>> client
>> > and Firefox I had to explicitly accept this discrepancy.
>> >
>> > The linux svn CLI yields this:
>> > # svn checkout https://.com/
>> > Error validating server certificate for 'https://.com:443':
>> > - The certificate is not issued by a trusted authority. Use the
>> >fingerprint to validate the certificate manually!
>> > - The certificate hostname does not match.
>> > Certificate information:
>> > - Hostname: nimble
>> > - Valid: from Tue, 16 Mar 2010 02:14:36 GMT until Fri, 13 Mar 2020
>> > 02:14:36 GMT
>> > - Issuer:
>> > - Fingerprint:
>> > 50:2b:50:a5:75:61:ae:f2:a0:d2:44:4f:12:6b:d3:6e:f8:c5:4b:12
>> > (R)eject, accept (t)emporarily or accept (p)ermanently?
>> >
>> > And if I accept this validation error, everything works properly.
>> >
>> > So I wonder if the error I'm getting from the Windows svn.exe is
>> related
>> > to my risky/invalid certificate. So one question I have is: how do I
>> > instruct svn to accept the certificate even though it's not completely
>> > valid?
>>
>> Maybe it is related to this change released in June 2010 in 1.6.12:
>>
>>* check for server certificate revocation on Windows (r898048)
>>
>>
>> r898048 | rhuijben | 2010-01-11 21:13:13 +0100 (Mon, 11 Jan 2010) | 10
>> lines
>>
>> Extend the (Windows only) ssl server certificate validation via
>> cryptoapi
>> with a certificate revocation check. Also use a proper certificate chain
>> verification, before trusting the certificate as valid instead of just
>> parsing the certificate status ourselves.
>>
>> * subversion/libsvn_subr/win32_crypto.c
>> (windows_validate_certificate): Add revocation check flag and verify
>> the
>> certificate chain as a ssl chain instead of reading the status of
>> the
>> leave certificate ourselves.
>>
>>
>>
>> Does Windows perhaps believe that the certificate has been revoked
>> for some reason? I cannot think of any other reason.
>>
>> Does it work if you try versions older than 1.6.12?
>>
>> > Any other suggestions?
>>
>> Try this:
>> svn checkout --non-interactive --trust-server-cert
>> https://.com/
>>
>> Stefan
>
