How to trust an expired SSL certificate with Subversion?

Question

Consider the following scenario. An old SVN server, accessible via HTTPS which has been moved to another domain (without new certificate) and whose certificate expired. I'm stuck with this situation as I have no influence on the remote end.

Equally I am stuck with this Subversion client version which comes with Scientific Linux 6.3:

$ svn --version
svn, version 1.6.11 (r934486)
   compiled Feb 10 2015, 17:07:04

I know about --non-interactive --trust-server-cert, but it doesn't help although the documentation suggests that these should be available and working in Subversion 1.6 versions. The error it gives me is:

svn: OPTIONS of 'https://svn.company.tld/svn/project/trunk': Server certificate verification failed: certificate has expired, certificate issued for a different hostname, bad certificate chain (https://svn.company.tld)

When I run it interactively I am only offered to accept the certificate temporarily or reject it. So all of the nice recipes suggesting to run interactively once and then run non-interactively are no good to me. In fact this is how I always did this on newer Subversion clients with Ubuntu. What I get to see is this (redacted):

Error validating server certificate for 'https://svn.company.tld:443':
 - The certificate hostname does not match.
 - The certificate has expired.
 - The certificate has an unknown error.
Certificate information:
 - Hostname: *.oldcompanyname.tld
 - Valid: from Tue, 02 Jun 2009 00:00:00 GMT until Wed, 06 Jul 2011 23:59:59 GMT
 - Issuer: www.digicert.com, DigiCert Inc, US
 - Fingerprint: fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd:fd
(R)eject or accept (t)emporarily?

Accepting temporarily allows me to cache the credentials and all, but it will prompt again to trust the certificate temporarily or reject it for every revision it pulls from the remote server.

So this is no option for me since I need it to be automated at the very least.

I also adjusted ~/.subversion/servers to contain:

[global]
ssl-authority-files = /home/username/.subversion/cacert-svn.pem

where the PEM file contains the edited contents (only the actual certificate blocks) from the output of the following openssl invocation:

openssl s_client -showcerts -connect svn.company.tld:443 < /dev/null > cacert-svn.pem

I also tried splitting these certificates into individual files and listing them in a semicolon-separated list (the docs aren't clear whether a single PEM file can contain multiple certificates for Subversion, I know for Apache this works). None of this works.

I also tried transplanting the ~/.subversion folder from a svn, version 1.8.8 (r1568071) to the Scientific Linux. This also fails.

How can I convince this given Subversion client to accept this particular certificate permanently despite having expired and being issued for a different host name?

---

Stuff I have read and that didn't help because it's either not applicable to my Subversion client or otherwise:

• bypass ssl certificate validation in subversion
• http://www.microhowto.info/howto/configure_subversion_to_trust_a_given_ssl_certificate.html
• https://serverfault.com/q/37929
• https://stackoverflow.com/a/9257625

Answer 1

You can use the following svn option:

--trust-server-cert-failures=unknown-ca,cn-mismatch,expired,not-yet-valid,other

Then it doesn't ask anymore in all? cases.