svn not accepting https/ssl certificate
Solution 1
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
Solution 2
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.
Related videos on Youtube
Comments
-
PeterCJ over 1 year
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.
-
PeterCJ over 8 yearsI 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 over 8 yearsRegarding the non-interactive pair of options, I had tried those, and they failed. :-(
-
PeterCJ over 8 yearsBut 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 over 8 yearsWith the lack of any other suggestions, I'll accept <<< t as my best workaround. Thanks.
-
PeterCJ over 8 yearsUnfortunately,
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.