Svn not accepting https/ssl certificate

certificatehttpssslsvn

When bettercodes.org disappeared in September, I moved my private repo over to https://subversion.assembla.com/. It's working great, except for the fact that I have to temporarily accept the certificate every time I interact with the server.

> svn --version
svn, version 1.8.4 (r1534716)

> svn update .
Updating '.':
Error validating server certificate for 'https://subversion.assembla.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate has an unknown error.
Certificate information:
 - Hostname: *.assembla.com
 - Valid: from Apr 16 13:31:17 2014 GMT until Mar 24 19:30:40 2016 GMT
 - Issuer: http://certs.godaddy.com/repository/, GoDaddy.com, Inc., Scottsdale, Arizona, US
 - Fingerprint: EC:9F:9D:B2:39:E1:34:81:7B:27:F6:51:30:8B:AC:41:5B:62:09:19
(R)eject or accept (t)emporarily? t

It doesn't give me the option to accept (p)ermanently, like my first few searches indicated it would. I am guessing it's because of the "unknown error".

Per https://serverfault.com/questions/27006/svn-wont-accept-my-invalid-certificate, I tried to update [global]:ssl-authority-files to include the cert from assembla, and set ssl-trust-default-ca to true. It still gives that error.

When that didn't work, I dug into the format of the ~/.subversion/auth/svn.ssl.server/___ files, figured out how to get the same name and encoding from the SSL certificate into that file, as if I had said "(p)ermanent"… but it still kept on giving that same error and prompt every time.

Over the course of time, I've meandered through other stackexchange answers, which have pointed me to things like downloading cacert.pem from curl.haxx.se and adding that to ssl-authority-files: when I try that, I get:

svn: E125009: Unable to connect to a repository at URL 'https://subversion.assembla.com/svn/[...my repo path...]'
svn: E125009: Invalid config: unable to load certificate file '/users/jonespet/.subversion/auth/ssl.certs/cacerts.pem'

I took the cacerts.pem back out, because it made things even worse, not better. 🙁

So I looked at the certificate for assembla using firefox, compared to the list of godaddy certs mentioned in the error above, and figured out which ones I thought I needed: I downloaded godaddy's gdroot-g2.crt and gdig2.crt, but that didn't help.

Using What does Subversion use for its CA list?, I tried

> openssl s_client -connect subversion.assembla.com:443 -showcerts
...
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.assembla.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/CN=*.assembla.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
---
SSL handshake has read 4910 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    ...
    Verify return code: 19 (self signed certificate in certificate chain)
---

I assume that return-code 19 is because of Go Daddy's Class 2 Certification Authority being self-signed. But I would have thought that would be okay, since I specifically told svn to trust that cert.

So, is there anything else I can do in order to get subversion to stop requiring me to temporarily accept that certificate? Or am I stuck hitting t for every update, commit, etc?


2015-Nov-23 EDITS

Per the comments, I went looking for the "some sort of error (other than code 19)", but haven't been able to replicate it. I think it must've my memory combining the "unknown error" from svn with the more detailed code 19 from openssl. So no new information on that front.

I tried going to some other linux boxes I have access to on other networks.

On one, it didn't have svn installed, but

# openssl version
OpenSSL 0.9.7m 23 Feb 2007

gives the same code 19 as above.

On the second, I get:

[~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
[~]# svn --version
svn, version 1.7.4 (r1295709)
   compiled Apr  5 2012, 16:46:24
[~]# openssl s_client -connect subversion.assembla.com:443 -showcerts
CONNECTED(00000003)
depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = *.assembla.com
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.assembla.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/CN=*.assembla.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5439 bytes and written 375 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: D5163A837AE5DEAFA2ED82B437F560A87DC7146FE819D9410B97174FAD7E2A67
    Session-ID-ctx:
    Master-Key: E4CCC925DC619A507ADAEEA688BD018A4419A0499C246764D9419542C1BF20F5A4C42B41FC6A776AD33915C20A83149B
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - aa ad c7 b3 f2 f1 1e 77-9b 4f f6 23 73 3b 75 70   .......w.O.#s;up
    0010 - dd bb 03 6c 96 31 b4 07-b0 55 b7 56 2f 32 c8 e5   ...l.1...U.V/2..
    0020 - da 46 06 27 53 79 18 a3-6d a4 8b f2 4c b1 8b e0   .F.'Sy..m...L...
    0030 - a2 04 ba 46 95 bb 3e c1-d3 72 69 59 01 18 2b 1c   ...F..>..riY..+.
    0040 - ba 5d dd ab 96 74 6e 01-db a2 96 54 75 de 4b f6   .]...tn....Tu.K.
    0050 - db ae c3 91 e4 fb fb 88-aa e3 f5 e1 bd bd 02 c8   ................
    0060 - c7 ef 54 63 2f d3 ae 4d-14 6b 47 fa 78 13 06 7f   ..Tc/..M.kG.x...
    0070 - a9 ba 31 23 b2 bf 6e 92-05 c3 35 ce 93 5f 2f 2e   ..1#..n...5.._/.
    0080 - 03 b3 f9 e7 f4 56 ed e7-c2 20 d9 65 8e b4 e2 e4   .....V... .e....
    0090 - 38 b6 e5 78 c0 af f8 12-ca 32 03 15 e2 a9 2a 4e   8..x.....2....*N
    00a0 - ec 62 6b 71 c1 dd 66 4a-96 1b f2 e9 e2 5d 86 96   .bkq..fJ.....]..
    00b0 - c2 3c 71 13 00 b3 16 f8-fd 45 7b 0d 2c aa 8f 6c   .<q......E{.,..l

    Start Time: 1448304537
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

And when I try to connect to my repo at assembla, it doesn't complain about the certificate. So that machine doesn't have an issue with the certificate chain. Apparently, it actually trusts GoDaddy.

Looking at some of the suggested certificate locations from https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/, on the machine that gives a code:0, I found

# ls -latr /etc/pki/tls/certs/ca-bundle.*
-rw-r--r-- 2 root root 1066943 Apr 23  2015 /etc/pki/tls/certs/ca-bundle.trust.crt
-rw-r--r-- 2 root root  877042 Apr 23  2015 /etc/pki/tls/certs/ca-bundle.crt

On today's first machine, without svn, it's in a different structure, but I did find that they had GoDaddy's cert

# ls -latr /etc/ssl/certs/Go*
lrwxrwxrwx 1 root root 58 Dec  8  2014 /etc/ssl/certs/Go_Daddy_Class_2_CA.pem -> /usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt

The next time I'm on the machine where I first started seeing these problems, I'll have to go looking around for the certificate store in those various directories, and see if something's out of date in the central locations.

But I guess now what I'd like the most help with: other than what's already been pointed out for svn, what svn or openssl settings should I look for in order to figure out why today's specific instance of openssl is accepting GoDaddy's root certificate, but the original instance of openssl gives it a code:19, when they're looking at the same certificate.


2015-Dec-04 EDITS

I couldn't find its central certificate location (no /etc/ssl or /etc/pki directories). At this point, there's probably not much else I can do on that particular machine to eliminate the error.

Best Answer

  • I would not recommend this for any serious use, but you can simply provide the 't' on standard input:

    svn update . <<< t
    

    Other option would be to use --trust-server-cert:

    svn --non-interactive --trust-server-cert update .
    

    It should be OK for your SVN version, it is added in 1.6 .

    Also see this thread, there is a nice expect solution provided: https://serverfault.com/questions/37929/how-do-you-accept-an-ssl-certificate-through-the-svn-command-line

  • Related Question