Greetings,
I'm at my wit's end trying to debug a troubling, highly irregular
issue connecting to a SVN server via HTTPS. I am very confident this
is a client issue, not a server issue. The server is CollabNet's
Subversion Edge server, which has 1.6.15 built in. The client is
1.6.15 running under Cygwin. I have many, many clients, most of which
are running Windows Server 2003 (if that matters)--all Cygwin, all
this same package. Lots of traffic every day. Almost all of it works
just fine.
Now, a very important fact: the svn operations WORK 95% of the time.
They just work. Everything is absolutely fine. This is an unattended,
fully-automated environment, launched from cron (well, Task Scheduler
when running on these Windows boxes). 95% of the time, the job
launches, runs my "svn update" command from within one of its working
copies:
svn update --username=some --password=thing --non-interactive
and it works beautifully.
Every "once in awhile," for absolutely no reason I can find (have
looked at logs, logs, logs, timing, the stars and planets,
everything), with absolutely nothing that I can find having changed,
it dies with this:
svn: OPTIONS of 'https://myserver:9999/svn/some/path': Server
certificate verification failed: certificate issued for a different
hostname, issuer is not trusted (https://myserver:9999)
(I have changed the paths/ports to protect the innocent).
Now for most of my clients, the "issued for a different hostname" part
is omitted--they still have the "issuer not trusted" part. That's
because my one host that I'm really digging in to debug this has to
use a different hostname for certain reasons. So, focus on the "issuer
not trusted" part because that's what we see across all clients.
But keep in mind: it works. It works 95% of the time. I change
absolutely nothing. Having found no indication of why it will
*randomly* fail with the above error, I decided to add the
"--trust-cerver-cert" flag, thinking surely this will eliminate all
woes. Just trust it and go (trust it like you already do 95% of the
time anyway)!
svn update --username=some --password=thing --non-interactive
--trust-server-cert
But, nope, I randomly get the very same error.
These key facts:
1) It works 95% of the time (well, maybe 85%)
2) I can find NOTHING changing (on client or server) between a working
op and a breaking op--it's all automated, and just randomly shanks
are leading me to believe that this error message is actually a
complete wild goose chase, and that the problem is not actually
cert-based but is something else (with a wrong error message). In
looking at the server HTTP logs, it does indeed appear that the client
bails out before continuing the connection--there's no log, meaning it
does appear that the client can't handshake (or refuses to), and then
quits.
I have thought about adding options to config (on the command line)
such as ssl-trust-default-ca, but again, I already told svn to
--trust-server-cert and it randomly still dies, so I don't think that
will help.
You'll be tempted to focus on SSL cert issues on the server or
something, but remember that we don't change anything and it works
fine almost all the time! (I'm still open to any thoughts of course).
Can anybody point me to some other debug options, some other flag, or
any other way to determine why, 15% of the time, it dies, yet 85% of
the time it updates just fine?
Thanks,
Dan
Received on 2011-07-25 20:13:18 CEST