bypass ssl certificate validation in subversion

Question

I\'m managing a subversion-based build system and we use a self-signed ssl for the server. So from time to time, we get build failures because a new machine has been added a

Answer 1

Another option is to use expect. Using expect you can simulate a user accepting the certificate. It will work when other options won't. I created this so that I could download code from svn in a Dockerfile.

#!/usr/bin/expect -f

set svn_username [lindex $argv 0]
set svn_password [lindex $argv 1]
set svn_url [lindex $argv 2]

spawn svn --username=${svn_username} --password=${svn_password} list ${svn_url}
expect "(R)eject, accept (t)emporarily or accept (p)ermanently? "
send -- "p\r"
expect "Store password unencrypted (yes/no)? "
send "no\r"
expect -re "root@.*:\/#"

Answer 2

I guess you have two options; throwing all caution overboard and setting trust-server-cert and non interactive from the command line:

 svn help co
 .... snip....
--non-interactive        : do no interactive prompting
--trust-server-cert      : accept unknown SSL server certificates without
                         prompting (but only with '--non-interactive')

and the other option is to use something like openssl s_client with -showcerts to check and validate if the cert has changed prior to the svn call -and then either abort very cleanly and let a human make the judgment call, or something dirty - like using the -showcert to update the known cert in ~/.subversion.

In either case - the bit of nonintuitive magic is on the files in ~/.subversion/auth/svn.ssl.server/<serverrecord> - to extract the cert info you need:

cat <serverrecord> | grep ^MII | base64decode  | openssl x509 -text -inform DER

or something like

cat <serverrecord> | grep ^MII | base64decode  | openssl x509 -text -inform DER -noout - out current-cert.pem

and can then use openssl s_client with -CApath or verify with that cert to see if it has changed and/or use -showcert to cross check. (Note: substitute perl -e 'use MIME::Base64;print decode_base64(join("",));' for base64decode if needed).

Answer 3

There are two possible scenarios: certificate is untrusted, but valid (i.e. a valid self-signed cert for example), or certificate is invalid (such as when you are accessing a machine on your LAN by IP or from outside your LAN by FQDN and that machine has a certificate issued to its symbolic name). svn client will not trust the 2nd type of cert even if using --trust-server-certificate option. In the 2nd scenario your only option I can think of is to use a hosts file entry to alias that machine's IP to its internal name.

Illustration of the scenario 2 that I once faced when VisualSVN was installed with all default option and generated a cert to the machine's symbolic name that it discovered:

LAN machine name MACHINE1 runs SVN server and it has a certificate installed that was issued to MACHINE1. You are trying to access SVN via its IP address and getting invalid certificate error.

You would also get that error if that MACHINE1 is accessible from outside your LAN by FQDN for example svn.domain.com and you are connecting to FQDN.

In both cases svn would throw the invalid certificate error.

You can add an entry to the hosts file to map the machine's IP address (LAN or external depending on where you are accessing it from) to the name certificate was issued to:

123.45.67.89 MACHINE1

and access SVN via https://machine1/svn/ to circumvent this situation.

Answer 4

under circtumstance you have another svn version, wich has no problems

so copy: cp -r .subversion/auth ...to the .subversion of affected system...