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://<mydomain>.com/<path> >> > svn: OPTIONS of 'https://<mydomain>.com/<path>': >> > SSL negotiation failed: SSL error code -1/1/336032856 >> > (https://<mydomain>.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://<mydomain>.com/<path> >> > Error validating server certificate for 'https://<mydomain>.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: <me> >> > - 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://<mydomain>.com/<path> >> >> Stefan >
