Re: authenticating with certificates & username/password

779 views
Skip to first unread message

michaelwiles

unread,
Jul 13, 2011, 8:40:50 AM7/13/11
to jenkins...@googlegroups.com
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.

Dustin Parker

unread,
May 2, 2012, 1:41:14 PM5/2/12
to jenkins...@googlegroups.com
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.

Dustin Parker

unread,
May 2, 2012, 2:34:18 PM5/2/12
to jenkins...@googlegroups.com
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>&lt;https://www.example.com/&gt;</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>&lt;https://www.example.com/&gt; 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!

Ryan

unread,
Jun 8, 2012, 4:49:07 PM6/8/12
to jenkins...@googlegroups.com
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>&lt;https://www.example.com/&gt;</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>&lt;https://www.example.com/&gt;</string>
      <hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
        <userName>username</userName>
        <password>YmFzZTY0LWVuY29kZWQgcGFzc3dvcmQ=</password>
      </hudson.scm.SubversionSCM_-DescriptorImpl_-PasswordCredential>
    </entry> 

and I get an SVNCancelException

Dustin Parker

unread,
Jun 11, 2012, 1:01:00 PM6/11/12
to jenkins...@googlegroups.com
The <string> element for the username/password entry must contain the hostname and the name of the basic authentication realm separated by a single space. One way to find this is to use curl:

$ curl -vk https://www.example.com/svn/repo
...
< HTTP/1.1 401 Authorization Required
< Date: Mon, 11 Jun 2012 16:58:23 GMT
< Server: Apache/2.0.54 (Win32) DAV/2 mod_ssl/2.0.54 OpenSSL/0.9.8g SVN/1.4.6 mod_wsgi/3.1 Python/2.6.5 mod_jk/1.2.31 mod_auth_sspi/1.0.1
< WWW-Authenticate: NTLM
< WWW-Authenticate: Basic realm="Subversion repositories"
< Content-Length: 596
< Content-Type: text/html; charset=iso-8859-1
...

Another way is to just get Firefox to prompt you for credentials for the site; the realm name should be in the dialog.
Reply all
Reply to author
Forward
0 new messages