Bug 448630 - neon+gnutls != neon+openssl for ne_ssl_trust_cert
Summary: neon+gnutls != neon+openssl for ne_ssl_trust_cert
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: neon
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-27 22:39 UTC by Emmanuel Thomé
Modified: 2008-10-14 13:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-14 12:31:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
CA file as stored in .subversion/ (1.67 KB, application/octet-stream)
2008-05-27 22:40 UTC, Emmanuel Thomé
no flags Details
certificate chain sent by server (9.35 KB, application/octet-stream)
2008-05-27 22:41 UTC, Emmanuel Thomé
no flags Details
openssl s_client output (OK) (28.18 KB, text/plain)
2008-05-28 11:12 UTC, Emmanuel Thomé
no flags Details
gnutls-cli output (FAILS) (5.72 KB, text/plain)
2008-05-28 11:16 UTC, Emmanuel Thomé
no flags Details

Description Emmanuel Thomé 2008-05-27 22:39:11 UTC
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.

Comment 1 Emmanuel Thomé 2008-05-27 22:40:11 UTC
Created attachment 306849 [details]
CA file as stored in .subversion/

Comment 2 Emmanuel Thomé 2008-05-27 22:41:47 UTC
Created attachment 306850 [details]
certificate chain sent by server

Comment 3 Joe Orton 2008-05-28 08:02:17 UTC
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?




Comment 4 Emmanuel Thomé 2008-05-28 11:12:35 UTC
Created attachment 306922 [details]
openssl s_client output (OK)

Comment 5 Emmanuel Thomé 2008-05-28 11:16:05 UTC
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.

Comment 6 Emmanuel Thomé 2008-05-28 11:24:35 UTC
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.

Comment 7 Simon Josefsson 2008-10-14 11:40:26 UTC
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

Comment 8 Joe Orton 2008-10-14 12:31:26 UTC
Thanks for the analysis, Simon!

Comment 9 Emmanuel Thomé 2008-10-14 12:50:50 UTC
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.

Comment 10 Simon Josefsson 2008-10-14 13:05:01 UTC
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


Note You need to log in before you can comment on or make changes to this bug.