I'm running into the same issue. Could you show an example of your final
configuration file? I'm using something very similiar to what is below,
and it's not working.
/var/lib/jenkins/hudson.scm.SubversionSCM.xml
/var/lib/jenkins/jobs/<jobname>/subversion.credentials
Both of the aforementioned files contain the following:
<entry>
<string><https://www.example.com/></string>
<hudson.scm.SubversionSCM_-DescriptorImpl_-SslClientCertificateCredential>
<certificate>cert is pasted in here</certificate>
<userName>username</userName>
<password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password>
</hudson.scm.SubversionSCM_-DescriptorImpl_-
SslClientCertificateCredential>
</entry>
<entry>
<string><https://www.example.com/></string>
<hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
<userName>username</userName>
<password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password>
</hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
</entry>
and I get an SVNCancelException
On Wednesday, May 2, 2012 2:34:18 PM UTC-4, Dustin Parker wrote:
>
> I did it!
>
> I looked at the files hudson.scm.SubversionSCM.xml and
> jobs/<jobname>/subversion.credentials. Both of them had, from a previous
> repository, an entry that looked like:
>
> <entry>
> <string><https://www.example.com/></string>
> <hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
> <userName>username</userName>
> <password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password>
> </hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
> </entry>
>
> and an entry that looked like:
>
> <entry>
> <string><https://www.example.com/> Subversion
> Repositories</string>
> <hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
> <userName>username</userName>
> <password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password>
> </hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
> </entry>
>
> so I gathered the former was for the *server* and the latter was for the
> *basic
> realm*. Even that wasn't true, this got me to realize that SVNKit would
> be *forced* to distinguish between the two: the realm isn't available
> until after the security has been negotiated, so if SVNKit is going to
> supply a password, it can only use the hostname. Then once the secure
> connection has been established, it will try to look up credentials in this
> map using the host and realm name. So I ginned up two entries: one with the
> certificate authentication and *only* the hostname, and another with
> password authentication and the host *and *realm names, just like above
> (only using certificate authentication for the first example). So far,
> crossing my fingers and toes, this seems to work!
>
> On Wednesday, May 2, 2012 10:41:14 AM UTC-7, Dustin Parker wrote:
>>
>> This issue (JENKINS-3912) is currently stalling our development effort,
>> too. I'm trying a variety of things to work around the issue. The
>> frustrating thing is that jsvn from the command line *works*, so the SVN
>> plugin is taking this functioning library and *breaking* it somehow.
>>
>> On Wednesday, July 13, 2011 5:40:50 AM UTC-7, michaelw wrote:
>>>
>>> Has this been resolved? Sorry to bring up such an old post but I have the
>>> same problem.
>>>
>>> The scenario is as follows:
>>>
>>> 1. SSL is configured on our apache server to require a client
>>> certificate -
>>> right at the front so you can't access any of the content if you don't
>>> have
>>> the client certificate.
>>> 2. The svn server is thus sitting behind the apache server - we thus use
>>> https to reach our svn server.
>>> 3. The svn server then has its own username/password resolution
>>> facilities,
>>> this is to do thing like permissions on svn folders etc.
>>>
>>> I can't get Jenkins to checkout my code.
>>>
>>> When I select the username/password option I get the following exception
>>>
>>> <wrapping exceptions removed>
>>>
>>> Caused by: java.lang.NullPointerException
>>> at
>>> org.apache.commons.io.FileUtils.openInputStream(FileUtils.java:129)
>>> at
>>> org.apache.commons.io.FileUtils.readFileToByteArray(FileUtils.java:1135)
>>> at
>>>
>>> hudson.scm.SubversionSCM$DescriptorImpl$SslClientCertificateCredential.<init>(SubversionSCM.java:1494)
>>> at
>>>
>>> hudson.scm.UserProvidedCredential$AuthenticationManagerImpl.getFirstAuthentication(UserProvidedCredential.java:205)
>>> at
>>>
>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initialize(HTTPSSLKeyManager.java:319)
>>> at
>>>
>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.initializeNoException(HTTPSSLKeyManager.java:301)
>>> at
>>>
>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPSSLKeyManager.chooseClientAlias(HTTPSSLKeyManager.java:196)
>>> at
>>>
>>> sun.security.ssl.AbstractWrapper.chooseClientAlias(SSLContextImpl.java:282)
>>> at
>>>
>>> sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:629)
>>> at
>>>
>>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:228)
>>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610)
>>> at
>>> sun.security.ssl.Handshaker.process_record(Handshaker.java:546)
>>> at
>>> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:913)
>>> at
>>>
>>> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1158)
>>> at
>>> sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:652)
>>> at
>>> sun.security.ssl.AppOutputStream.write(AppOutputStream.java:78)
>>> 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:229)
>>> at
>>>
>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:166)
>>> at
>>>
>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:364)
>>> ... 59 more
>>>
>>> Almost as if it is looking for a client certificate file but as one isn't
>>> set, it cannot find one.
>>>
>>> Then if I try the other option - client certificate I get:
>>>
>>> Attempting an SSL client certificate authentcation
>>> Passing user name null and password you entered
>>> Failed to authenticate: org.tmatesoft.svn.core.SVNErrorMessage: svn:
>>> OPTIONS
>>> of /OldMutual/sandbox/trunk/maven/parent: 401 Authorization Required
>>> (https://svn.afrozaar.com)
>>>
>>> So it looks like it is getting passed the https level but being locked
>>> out
>>> by the svn authentication.
>>>
>>> The interesting thing about this scenario is that the log says "Passing
>>> username null and password you entered" - almost as if if the password
>>> was
>>> set, it would work.
>>>
>>> The .subversion config is configured correctly - so I'm not sure if it is
>>> reading this.
>>>
>>> --
>>> View this message in context:
>>> http://jenkins.361315.n4.nabble.com/authenticating-with-certificates-username-password-tp373150p3664923.html
>>> Sent from the Jenkins users mailing list archive at Nabble.com.
>>>
>>>
