Server Certificate Verification Failed:certificat

> PROPFIND request failed on '/svn/superscout '
> PROPFIND of '/svn/superscout ': Server certificate verification
> Failed:certificate issued for a different hostname, issuer are 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 lsHttps://82.100.10.110/svn/Superscout 
"
3. You'll get a text prompt about the server's certificate, asking you
What does
4. Type "P" (and return), meaning "permanently accept this certificate
anyway "

That answer'll be saved away in a place that both the command line
"SVN" and also scplugin would 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-of-the-use SVN.
HTTP servers can, and often do, use of an encrypted connection, called
"https". Subversion can do, too, and that 's what ' s going on here.

The encryption includes a "server certificate," a digital signature
That proves, the server you ' re talking to really are the one you
think it is. This is included because it's possible to arrange so
That connections think is going to one computer actually go
another. There ' s an attack called the "Mans in the middle," where some
Bad person sets things up the this to 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 on the Middle" is reading everything. Unfortunately, there is
no-to-detect or prevent this from the stream of messages alone.

The server certificate protects you against this, because the server
certificates is digitally signed by someone else. the idea was that
there should be a few signatories so 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's the person was ; you ' ve seen driver ' s licenses before and can spot a
phony (at least, if it's not too good a phony), and so have seen the
license, you can trust that the person was who they claim to be.

This process isn ' t working for you. The messages actually say there
is 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 this by showing your a license for "Fred Smithers," you're d be
More than a little suspicious, right? Same thing here. However, this
is probably because your told Subversion to contact "https://82.100.10.110 
"-That's, the server's" name "is 82.100.10.110. That ' s the host
*address*, but typically the server ' s actual certificate are for their
host *name*. If you try again, using "https:// 
server.superscout.co.uk "(or whatever the name actually is)
Would 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 was internal to your company network, and so conceivably
You are not having DNS properly set up for it. Maybe that's why you used
An address rather than a name. At any rate, the procedure above would
reassure Subversion is OK for this combination really.

in the second problem:metaphorically, Subversion was saying " this
looks like a driver's license, but it's from some country I ' ve never
heard of, how does I know whether it's a valid license from there? "
Actually, there's a good chance that this certificate was signed by one
Of the standard Authorities:there ' s a bugs in OS X about the
installation of this information, as a result of which Subversion (and
scplugin) requires some extra configuration work on order to find the
List of trusted authorities. If you ' re going to being connecting to a
great many different servers, it might be worth your and to fix
This . That can is done, but until Apple fixes the bug it also means
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 are only having to do it a few times, you ' re better off just doing it
than fixing the Authority list. But if you want to the list of fix up,
You can find the "directions in the " [email protected] list on Scplugin. Or, just
ask there again, and someone'll restate them, or point-to-them.




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

Server Certificate Verification Failed:certificat