HTTPS Subversion 1.7 and Jenkins - issuer not trusted

[Adam Retter]

Our Subversion server is operating over HTTPS and works fine typically form the command line. We are using a self-signed certificate and the first time we do an 'svn co' locally we have to of course permanently accept the certificate. However I cannot seem to get Jenkins to work with our Subversion server.

[ERROR] svn: E175002: Unable to connect to a repository at URL 'https://wb-d-tfs2.web.local/svn/dp/trunk/byteseek'
svn: E175002: OPTIONS of 'https://wb-d-tfs2.web.local/svn/dp/trunk/byteseek': Server certificate verification failed: issuer is not trusted (https://wb-d-tfs2.web.local)

I really dont want to have to but a certificate just to get Jenkins to work. How can I fix this please?

The full build log from Jenkins is here - 

At revision 130
no change for https://wb-d-tfs2.web.local/svn/dp/trunk/byteseek since the previous build
Parsing POMs
[workspace] $ "C:\Program Files\Java\jdk1.6.0_32/bin/java" -cp D:\Jenkins\plugins\maven-plugin\WEB-INF\lib\maven3-agent-1.2.jar;D:\Jenkins\tools\Maven\Apache_Maven_3.0.4\boot\plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main D:\Jenkins\tools\Maven\Apache_Maven_3.0.4 D:\Jenkins\war\WEB-INF\lib\remoting-2.16.jar D:\Jenkins\plugins\maven-plugin\WEB-INF\lib\maven3-interceptor-1.2.jar 61319
<===[JENKINS REMOTING CAPACITY]===>channel started
log4j:WARN No appenders could be found for logger (org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
Executing Maven:  -B -f D:\Jenkins\jobs\byteseek TNA\workspace\pom.xml install
[INFO] Scanning for projects...
Projects to build: [MavenProject: byteseek:byteseek-tna:1.1.1-SNAPSHOT @ D:\Jenkins\jobs\byteseek TNA\workspace\pom.xml]
projectStarted byteseek:byteseek-tna:1.1.1-SNAPSHOT
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building byteseek-tna 1.1.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
mojoStarted org.codehaus.mojo:buildnumber-maven-plugin:1.1(default)
[INFO] 
[INFO] --- buildnumber-maven-plugin:1.1:create (default) @ byteseek-tna ---
[INFO] Verifying there are no local modifications ...
[INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
[INFO] Working directory: D:\Jenkins\jobs\byteseek TNA\workspace
[INFO] Executing: cmd.exe /X /C "svn --non-interactive update "D:\Jenkins\jobs\byteseek TNA\workspace""
[INFO] Working directory: D:\Jenkins\jobs\byteseek TNA\workspace
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: E175002: Unable to connect to a repository at URL 'https://wb-d-tfs2.web.local/svn/dp/trunk/byteseek'
svn: E175002: OPTIONS of 'https://wb-d-tfs2.web.local/svn/dp/trunk/byteseek': Server certificate verification failed: issuer is not trusted (https://wb-d-tfs2.web.local)

mojoFailed org.codehaus.mojo:buildnumber-maven-plugin:1.1(default)
projectFailed byteseek:byteseek-tna:1.1.1-SNAPSHOT
sessionEnded
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.524s
[INFO] Finished at: Fri Jul 13 18:30:12 BST 2012
[INFO] Final Memory: 10M/111M
[INFO] ------------------------------------------------------------------------
Projects to build: [MavenProject: byteseek:byteseek-tna:1.1.1-SNAPSHOT @ D:\Jenkins\jobs\byteseek TNA\workspace\pom.xml]
[JENKINS] Archiving D:\Jenkins\jobs\byteseek TNA\workspace\pom.xml to D:\Jenkins\jobs\byteseek TNA\modules\byteseek$byteseek-tna\builds\2012-07-13_18-30-03\archive\byteseek\byteseek-tna\1.1.1-SNAPSHOT\byteseek-tna-1.1.1-SNAPSHOT.pom
Waiting for Jenkins to finish collecting data
mavenExecutionResult exceptions not empty
message : Failed to execute goal org.codehaus.mojo:buildnumber-maven-plugin:1.1:create (default) on project byteseek-tna: Couldn't update project. Error!
cause : Couldn't update project. Error!
Stack trace : 
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:buildnumber-maven-plugin:1.1:create (default) on project byteseek-tna: Couldn't update project. Error!
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
	at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:326)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.maven.plugin.MojoExecutionException: Couldn't update project. Error!
	at org.codehaus.mojo.build.CreateMojo.update(CreateMojo.java:588)
	at org.codehaus.mojo.build.CreateMojo.execute(CreateMojo.java:440)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	... 27 more
Caused by: org.apache.maven.scm.ScmException: Error!
	at org.codehaus.mojo.build.CreateMojo.checkResult(CreateMojo.java:825)
	at org.codehaus.mojo.build.CreateMojo.update(CreateMojo.java:575)
	... 30 more
Sending e-mails to: <omitted>
channel stopped
Sending e-mails to: <omitted>
Finished: FAILURE

[Jan Seidel]

Hi Adam,

Your server is already using a certificate, so this is nothing you have to worry about anymore in order to get Jenkins running ;)
Install the server certificate on the machine running Jenkins in the trusted cert store.
Note you may have to install it in various stores.

• ssh to the server and accept the certificate permanently.
• Save a copy of the certificate to a convenient location.
• Install the certificate to the OS' cert sotre
  
• Install the certificate in the Java cert store with the key-tool
• Run a simply svn command like list/info/whatever from a shell/command box and accept the cert if prompted so.
• Same counts for vairous tools you have installed to access SVN. Problem here is that each tool comes along with its own solution/store. Registry/OS' cert store/own cert store/User's home and so on and so on.
  

The annoying part here is that it not always has to happen that the SVN plugin uses a dedicated cert store. It may rather depend on which installation order of the different svn tools. Some of them seem to hamper around with the OS and gives you some real hard time to locate the appropriate storage.
Try the steps mentioned above. Use Systernal's ProcMon to trace Jenkins if you didn't solve your issue with the steps mentioned above. ProcMon does the trick and saves you a big deal of time compared to root cause analysis without tracing.

HTH
Jan

[Adam Retter]

Hi Jan,

Thanks for your reply I have finally solved this, unfortunately it was not as simple as I hoped (probably due to the fact our platform is on Windows Server).

The point you raised below, gave me a good hint -

• Run a simply svn command like list/info/whatever from a shell/command box and accept the cert if prompted so.

So looking at the build output, I could tell that the 'buildnumber' Maven plugin was directly calling svn, so this was outside of Jenkins awareness really. I then realised that Jenkins was running as the 'SYSTEM' user and so that svn command was being executed by the SYSTEM user. Obviously the SYSTEM user needed to accept the server certificate and provide authentication, which it didnt had.

I located where svn keeps its auth details for the SYSTEM user on Windows 2008 Server - C:\Windows\System32\config\systemprofile\AppData\Roaming\Subversion\auth and I copied in appropriate authentication files to the svn.simple and and svn.ssl.server folders from another account where I knew the build worked. It did now accept the SSL cert but refused to authenticate.

So no luck doing that. I then tried a different approach. I re-installed Jenkins making sure that it would run under a custom user account called - "s-subversion" and configured the Windows service appropriately to use that account. When I tried to build the project I had the same issue again, but I could now open a command prompt running as the 's-jenkins' user and execute 'svn up' in the job's workspace, svn then prompted me to accept the server certificate and enter a username and password. After that running the build again in Jenkins now works perfectly.

I have added the detail above to try and assist future Windows server users.

Thanks

 

[Sreekumar R]

Adam Retter <adam.retter@...> writes:

Hi,

I had figured out a solution for this.

Just login to the Windows Server with any user credentials.
Open Command Prompt,

set USERNAME=SYSTEMNAME$ (Whatever USERNAME is used as per the Jenkins)
set USERDOMAIN=DOMAIN (Whatever DOMAINNAME is used as per the Jenkins)
set USERPROFILE=C:\Windows\System32\config\systemprofile (same as the
one taken by Jenkins)

Then run svn command, so it will check for the username and profile
folder and come up with asking for svn credentials and it will get saved
as encrypted in the folders under

C:\Windows\System32\config\systemprofile\AppData\Roaming\Subversion\auth

Thanks,
Sreekumar R

[Sreekumar R]

Adam Retter <adam.retter@...> writes:

Hi,

I had figured out a solution for this.

Just login to the Windows Server with any user credentials.
Open Command Prompt,

set USERNAME=SYSTEMNAME$ (Whatever USERNAME is used as per the Jenkins)
set USERDOMAIN=DOMAIN (Whatever DOMAINNAME is used as per the Jenkins)
set USERPROFILE=C:\Windows\System32\config\systemprofile (same as the
one taken by Jenkins)

Then run svn command, so it will check for the username and profile
folder and come up with asking for svn credentials and it will get saved
as encrypted in the folders under

C:\Windows\System32\config\systemprofile\AppData\Roaming\Subversion\auth

Thanks,
Sreekumar R