Bug 448630 - neon+gnutls != neon+openssl for ne_ssl_trust_cert
neon+gnutls != neon+openssl for ne_ssl_trust_cert
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: neon (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Joe Orton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-27 18:39 EDT by Emmanuel Thomé
Modified: 2008-10-14 09:05 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-14 08:31:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Emmanuel Thomé 2008-05-27 18:39:11 EDT
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 18:40:11 EDT
Created attachment 306849 [details]
CA file as stored in .subversion/
Comment 2 Emmanuel Thomé 2008-05-27 18:41:47 EDT
Created attachment 306850 [details]
certificate chain sent by server
Comment 3 Joe Orton 2008-05-28 04:02:17 EDT
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 07:12:35 EDT
Created attachment 306922 [details]
openssl s_client output (OK)
Comment 5 Emmanuel Thomé 2008-05-28 07:16:05 EDT
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 07:24:35 EDT
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 Need Real Name 2008-10-14 07:40:26 EDT
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@normalesup.org
 # Issuer's DN: CN=https,EMAIL=Emmanuel.Thome@normalesup.org

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@normalesup.org
 # Issuer's DN: CN=https,EMAIL=Emmanuel.Thome@normalesup.org

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@normalesup.org
 # Issuer's DN: C=FR,ST=Lorraine,L=Nancy,O=INRIA Lorraine,OU=CACAO,CN=CA-CACAO,EMAIL=Emmanuel.Thome@normalesup.org

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 08:31:26 EDT
Thanks for the analysis, Simon!
Comment 9 Emmanuel Thomé 2008-10-14 08:50:50 EDT
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 Need Real Name 2008-10-14 09:05:01 EDT
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.