This problem emanated from subversion's ssl-authority-files options. I have: [global] ssl-authority-files = /users/cacao/thome/.subversion/cacacao.pem ssl-trust-default-ca = false Despite this, when connecting to an https svn server whose certificate is signed by the ``cacacao'' CA above, subversions tags the certificate as invalid ``not signed by a trusted authority''. If I substitute the version of neon27 for one compiled with --with-ssl=openssl, then it works as it always has: according to the ssl-authority-files, my CA certificate is accepted. The certificate files in question, as well as the certificate chain sent by the server, follow as attachments. Regards, E.
Created attachment 306849 [details] CA file as stored in .subversion/
Created attachment 306850 [details] certificate chain sent by server
Is there a public server using a cert signed by this CA which I can try? Can you capture the output of: $ gnutls-cli --x509cafile /users/cacao/thome/.subversion/cacacao.pem \ -V -p 443 the.server.host.name and separately: $ openssl s_client -CAfile /users/cacao/thome/.subversion/cacacao.pem \ -debug -showcerts -connect the.server.host.name:443 and attach both to this bug report?
Created attachment 306922 [details] openssl s_client output (OK)
Created attachment 306923 [details] gnutls-cli output (FAILS) I'm not familiar with gnutls-cli ; should this normally work ? When I do cat server_chain.crt .subversion/cacacao.crt | certtool -e then the verification succeeds.
You may try profiterolle.dyndns.org:443 ; however, this is a port forward to the same server as above, so obviously certificate checking will choke on the hostname unless you cheat with /etc/hosts. I see unchanged results on my side.
The server is misconfigred: the certificate chain is not returned in signing order: - Certificate[0] info: # The hostname in the certificate matches 'tiramisu'. # valid since: Wed Dec 19 12:47:14 CET 2007 # expires at: Tue Dec 18 12:47:14 CET 2057 # fingerprint: 2E:3D:64:A4:2B:2E:2B:0F:56:96:07:9E:95:77:DE:35 # Subject's DN: CN=tiramisu,EMAIL=Emmanuel.Thome # Issuer's DN: CN=https,EMAIL=Emmanuel.Thome Right, that's the end-entity certificate. - Certificate[1] info: # valid since: Wed Dec 19 12:47:14 CET 2007 # expires at: Tue Dec 18 12:47:14 CET 2057 # fingerprint: 2E:3D:64:A4:2B:2E:2B:0F:56:96:07:9E:95:77:DE:35 # Subject's DN: CN=tiramisu,EMAIL=Emmanuel.Thome # Issuer's DN: CN=https,EMAIL=Emmanuel.Thome This is the end-entity certificate again? - Certificate[2] info: # valid since: Wed Nov 14 11:01:26 CET 2007 # expires at: Tue Nov 13 11:01:26 CET 2057 # fingerprint: 97:50:FE:F2:C5:83:E3:E0:B3:8F:80:ED:AB:E8:20:1A # Subject's DN: CN=https,EMAIL=Emmanuel.Thome # Issuer's DN: C=FR,ST=Lorraine,L=Nancy,O=INRIA Lorraine,OU=CACAO,CN=CA-CACAO,EMAIL=Emmanuel.Thome This looks like the proper issuer certificate. The solution is to remove the middle certificate. Possibly you have the end-entity certificate duplicated in your CA file? This is forbidden by the RFC: certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. There is a long discussion about this on the IETF TLS WG list: http://permalink.gmane.org/gmane.ietf.tls/3782 /Simon
Thanks for the analysis, Simon!
Thanks much. Sorry for not having noticed the pitfall. Somehow I got spoofed by apache requiring both a SSLCertificateFile and a SSLCertificateChainFile ; The former apparently can't be a chain. I hadn't realized that this required the latter to be necessarily incomplete, since in the end apache sends both. E.
I think it is a documentation bug in mod_ssl, it says "usually in in certificate chain order": http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslcertificatechainfile It could be a bit more clear that mod_ssl will violate the TLS protocol if you don't. It is fairly clear that the chain should not contain the end entitity certificate, though, although I guess it wouldn't hurt to make that explicit. Btw, a better link to the discussion is: http://thread.gmane.org/gmane.ietf.tls/3782 /Simon