使用VisualSVN Server配置hook时遇到问题:Server certificate verification failed

      在使用VisualSVN Server建立了SVN服务端后,为一个版本库设置post-commit hook.遇到类似下面

的错误信息:

      Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted

 

      Google了一些资料,找到下面这个web:

      Server certificate verification failed: certificate issued for a different hostn

      此web内容在最后将转帖出来.

 

      参照上述web给出的方式进行操作后,仍然遇到之前的错误信息.根据文中的解释,判断

应该对VisualSVN Server提供的Certificate信息做调整.

      在VisualSVN的Properties设置中,找到'Certificate'选项卡,对'Certificate Information'进行更改.

因为使用post-commit hook去更新指定的workcopy目录,而workcopy目录访问SVN时采用IP地址,

故在'Certificate Information'中,也采用的是相同的IP地址.修改完成,重启VisualSVN Server,重新

测试post-commit,上述的错误将被消除.

      另外,要注意的是,Certificate Information是有时效的.

 

      下面转帖上面的web中的内容:

> PROPFIND request failed on '/svn/Superscout'
> PROPFIND of '/svn/Superscout': Server certificate verification 
> failed: certificate issued for a different hostname, issuer is not 
> trusted (https://XX.XX.XX.XX)

First, here's how to fix the situation:

1. Open Terminal (in Utilities, in Applications)
2. Type some svn command against your repository, say "svn ls https://82.100.10.11​0/svn/Superscout 
"
3. You'll get a text prompt about the server's certificate, asking you 
what to do
4. Type "p" (and return), meaning "permanently accept this certificate 
anyway"

That answer will be saved away in a place that both the command line 
"svn" and also SCPlugin will reuse.

Now, the explanation, in case you're curious:

You're accessing Subversion through the HTTP protocol, the same one 
used by web browsers. This is probably the most common way to use SVN. 
HTTP servers can, and often do, use an encrypted connection, called 
"https". Subversion can do that, too, and that's what's going on here.

The encryption includes a "server certificate," a digital signature 
that proves that the server you're talking to really is the one you 
think it is. This is included because it is possible to arrange so 
that connections you think are going to one computer actually go to 
another. There's an attack called the "man in the middle," where some 
bad person sets things up this way, then forwards messages back and 
forth between you and the true server. Your web browser (or 
Subversion) sends and receives exactly the packets it expects to, but 
the "man in the middle" is reading everything. Unfortunately, there is 
no way to detect or prevent this from the stream of messages alone.

The server certificate protects you against this, because the server 
certificates are digitally signed by someone else. The idea is that 
there should be a few signatories that you trust to do this, and you 
can confirm that one of these signed a given server's certificate, and 
hence you trust that it's the one you want. This is the same as 
checking a person's driver's license: you trust the state to attest 
who the person is; you've seen driver's licenses before and can spot a 
phony (at least, if it's not too good a phony), and so having seen the 
license, you can trust that the person is who they claim to be.

This process isn't working for you. The messages actually say there 
are two problems:

- certificate issued for a different hostname
- issuer is not trusted

In the first problem: if I claim to be "Jack Repenning," and attempt 
to prove that by showing you a license for "Fred Smithers," you'd be 
more than a little suspicious, right? Same thing here. However, this 
is probably because you told Subversion to contact "https://82.100.10.110 
" -- that is, the server's "name" is 82.100.10.110. That's the host 
*address*, but typically the server's actual certificate is for their 
host *name*. If you try again, using "https:// 
server.superscout.co.uk" (or whatever the name actually is), this part 
will probably go away. But maybe not: when I try to look up that 
address in the global DNS name base, I don't get a reply. Probably 
that address is internal to your company network, and so conceivably 
you may not have DNS properly set up for it. Maybe that's why you used 
an address rather than a name. At any rate, the procedure above will 
reassure Subversion that this combination really is OK.

In the second problem: metaphorically, Subversion is saying "this 
looks like a driver's license, but it's from some country I've never 
heard of, how do I know whether it's a valid license from there?" 
Actually, there's a good chance that this certificate is signed by one 
of the standard authorities: there's a bug in OS X about the 
installation of this information, as a result of which Subversion (and 
SCPlugin) requires some extra configuration work in order to find the 
list of trusted authorities. If you're going to be connecting to a 
great many different servers, it might be worth your while to fix 
this. That can be done, but until Apple fixes the bug it also means 
you have to manually update it from time to time (about once a year), 
which would be tiresome.

The procedure above works once for all time, for this one address. If 
you only have to do it a few times, you're better off just doing it 
than fixing the authority list. But if you want to fix up the list, 
you can find the directions in the users@ list on scplugin. Or, just 
ask there again, and someone will restate them, or point you to them.

-==-
Jack Repenning
jackrepenning at tigris dot org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"