Or to state the below (pardon the top-post) much more simply: the
--trust-server-cert flag does not work. It fails to perform its
singular function, which is...to force trust of the server cert,
right?
(Though I still think something else is going on, I can start there).
On Mon, Jul 25, 2011 at 1:12 PM, Dan Yost <yodano_at_gmail.com> wrote:
> 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-26 19:58:05 CEST