在使用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.110/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"