We are having a mysterious problem with https: access to subversion, and
I think there's a subtle bug somewhere in the svn/neon/openssl chain.
At BBN we have a number of systems running apache22/subversion,
accessible only over ssl. We have a local CA and server certs on the
systems signed by the CA. Client systems that have the CA cert
installed in /etc/openssl/certs or equivalent operate with no trouble.
Without the CA cert installed, the expected behavior is to get a prompt
From subversion on the first access, where the user will select 'p' and
cause a file to be created in ~/.subversion/auth/svn.ssl.server/ . But,
a number of clients, at least on NetBSD and cygwin, instead print:
svn: OPTIONS of 'https://foo.example.com/svn/bar/bar-cm/empty': SSL handshake failed: SSL error: certificate verify failed (https://foo.example.com)
without prompting the user. cygwin systems seems to be failing
regularly. These problems happen even on systems which have previously
(p)ermanently accepted the unknown-CA cert.
An example build that exhibits the problem is:
svn, version 1.6.5 (r38866)
compiled Nov 29 2009, 20:59:51
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
But, another computer with the same version (but built independently) do
not seem to have the problem, at least at some times.
Running ktrace on the client, I see it try to stat the hash of the issuer DN and then
immediately fail and close the connection.
15349 1 svn NAMI "/etc/openssl/certs/b14afcb7.0"
15349 1 svn RET __stat30 -1 errno 2 No such file or directory
15349 1 svn CALL write(4,0xbb5b5000,7)
15349 1 svn GIO fd 4 wrote 7 bytes
"\^U\^C\0\0\^B\^B*"
15349 1 svn RET write 7
15349 1 svn CALL close(4)
15349 1 svn RET close 0
15349 1 svn CALL write(2,0xbb52e1a8,0x9b)
15349 1 svn GIO fd 2 wrote 155 bytes
"svn: OPTIONS of [as above]
With the CA cert, that stat succeeds and validation continues.
It seems that when the premature failure happens there is no attempt to
stat the svn-local certificate file under ~/.subversion/auth/.
There may be something wrong with our certificates, of course, but
firefox and svn are both happy with them if the CA cert is installed,
and firefox prompts normally when the CA cert is not installed.
I wonder if neon/openssl has some ambiguity about return codes that is
causing what should turn into prompt-if-ok to be a fatal error without
that.
With neon-debug-mask = 255, I get:
ah_create, for WWW-Authenticate
Running pre_send hooks
compress: Initialization.
compress: Initialization.
Sending request headers:
OPTIONS /svn/bar/bar-cm/empty HTTP/1.1
User-Agent: SVN/1.6.5 (r38866) neon/0.29.0
Keep-Alive:
Connection: TE, Keep-Alive
TE: trailers
Host: foo.example
Content-Type: text/xml
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Content-Length: 104
Accept-Encoding: gzip
Sending request-line and headers:
Doing DNS lookup on foo.example...
Connecting to [redacted, but right]
sess: Closing connection.
sess: Connection closed.
Request ends, status 0 class 0xx, error line:
SSL handshake failed: SSL error: certificate verify failed
Running destroy hooks.
Request ends.
svn: OPTIONS of 'https://foo.example/svn/bar/bar-cm/empty': SSL handshake failed: SSL error: certificate verify failed (https://foo.example)
sess: Destroying session.
sess: Destroying session.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2426779
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
- application/pgp-signature attachment: stored
Received on 2009-12-03 19:05:22 CET