5

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.

2 Answers 2

2

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

4
  • I hadn't thought of bringing in the 't' response via command line. My problem with the t or expect solutions is that they mask/avoid, rather than solve the underlying problem. Given the lack of other options, I might just implement one of those, but only reluctantly...
    – PeterCJ
    Nov 21, 2015 at 1:45
  • Regarding the non-interactive pair of options, I had tried those, and they failed. :-(
    – PeterCJ
    Nov 21, 2015 at 1:47
  • But that reminded me, during my experiments, I tried some command-line openssl interaction. I seem to remember that it indicated some sort of error in the assembla cert or chain (beyond the code 19), but I don't remember exactly what. At my next opportunity, I will have to explore that path again, though I'm really not very good with the cert/ssl aspect of things....
    – PeterCJ
    Nov 21, 2015 at 1:58
  • With the lack of any other suggestions, I'll accept <<< t as my best workaround. Thanks.
    – PeterCJ
    Dec 5, 2015 at 3:31
1

Partial answer for openssl s_client verify error 19 only: depending on the OpenSSL versions and builds you use it might 'reject' the cert even though the CA root is in the local truststore; see SSL Root CA certificate is not recognized, although present in the trust store. Why? .

If your "works okay" system is RedHat-family, check the version including patches e.g. 1.0.1e -42.el6 in rpm or yum etc, not the output of openssl version which is the upstream version before patching. On the "trouble" system(s) if the version looks old or possibly so, look at openssl version -d and try -CApath with that directory if it contains individual files with names or links mostly in hex, or -CAfile with that directory plus /cert.pem if it exists -- even though these logically should be redundant.

But this issue wouldn't affect svn so it doesn't help with your underlying problem.

1
  • Unfortunately, openssl s_client -CAfile /usr/share/ssl/cert.pem -connect subversion.assembla.com:443 -showcerts still gives the same error 19, as does the CApath variant. But I did find the certs/ca-bundle.crt file is from 2007. When I tried to point CAfile at a more recent bundle I downloaded, it still gives error 19. I think without having root access, I don't think there's much I could do. But I did learn a bit more about the configuration and some debug options, so thanks for your answer.
    – PeterCJ
    Dec 8, 2015 at 0:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .