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
