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 <yod...@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 >
