A quick update, I have found a work around to this issue. In the .subversion directory under the Jenkins user's home directory, there is the "servers" file which specifies subversion server specific protocol parameters. I had previously configured this file with a group name and url for my subversion server. And in the section for the corresponding group name , I previously specified paths to the SSL authority files (PEMs) and for the SSL client certificate file (P12), as was necessary to use SVN from the command line for this server. In my attempt to workaround this exception, I added the SSL client certificate password to this file, so that I could configure Jenkins to checkout from subversion via a shell command. I discovered by accident that after configuring it in this way, I was able to checkout from subversion using the SVNplugin as normal, which leads me to suspect that there must be a bug of some sort associated with the interface at <Jenkins URL>/scm/SubversionSCM/enterCredential
While this workaround is acceptable, I would prefer not to have any client certificate passwords in the servers file. Does anyone here know of any issues regarding the interface I mentioned above ? On Wednesday, January 9, 2013 10:03:16 AM UTC-8, Andrew Bayless wrote: > > Hello, > > I am having problems authenticating against a local subversion repository > using the subversion plug-in. I am using Jenkins 1.497 with the Subversion > 1.44 plugin deployed on Winstone, running on CentOS 6.3. I am also using > JDK 1.7 to run Jenkins and Winstone. I am using a subversion repository, > version 1.7, configured to authenticate via HTTPS client certificates. > > After entering the path to a PKCS12 certificate and providing the correct > password, I am receiving this exception : > > Attempting an SSL client certificate authentcation > Failed to authenticate: svn: E170001: SSL handshake failed: 'Received fatal > alert: handshake_failure' > > Tracing the stack of exceptions, the root of it appears to be this : > > Caused by: java.lang.NullPointerException > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.loadClientCertificate(HTTPSSLKeyManager.java:187) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initialize(HTTPSSLKeyManager.java:441) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initializeNoException(HTTPSSLKeyManager.java:406) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.chooseClientAlias(HTTPSSLKeyManager.java:302) > at > sun.security.ssl.AbstractKeyManagerWrapper.chooseClientAlias(SSLContextImpl.java:1029) > at > sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:703) > at > sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:282) > at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868) > at sun.security.ssl.Handshaker.process_record(Handshaker.java:804) > at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:966) > at > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1262) > at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:680) > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:85) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.sendData(HTTPConnection.java:238) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:168) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:385) > ... 63 more > > I have attempted a similar configuration changing certain elements (however I > cannot change any configurations or software version on the local SVN repo). > I have attempted to deploy Jenkins via GlassFish, have attempted to running > it on JDK 1.6 update 37 > on both Winstone and GlassFish, have attempted to downgrade the Subversion > plug-in and run it in the previous configurations. I was still running into > this exception in all these configurations, until I tried running everything > on a different machine on CentOS 5.8, > at which point I am not encountering this exception and am successfully able > to authenticate, check-out working copies and execute build jobs normally. > > For now, I am able to use Jenkins successfully, but I might need to use > Jenkins to build a larger scale build server than what I am using now, in a > CentOS 6.3 enviroment. Is anyone here familiar with this exception ? Does > anyone here have any tips on how to work around this ? > Is this an issue, or is there a mistake I am making somewhere ? > > Thank You, > Andrew > >
