After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 589323 - SSL verification fails due to not setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
SSL verification fails due to not setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
Product: libsoup
Classification: Core
Component: Misc
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
Depends on:
Reported: 2009-07-22 06:28 UTC by Patrick Ohly
Modified: 2009-07-26 17:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

minor fix: check that gnutls_certificate_allocate_credentials() really succeeded (1.03 KB, patch)
2009-07-23 14:14 UTC, Patrick Ohly
rejected Details | Review
set GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT (1.93 KB, patch)
2009-07-23 14:16 UTC, Patrick Ohly
committed Details | Review

Description Patrick Ohly 2009-07-22 06:28:08 UTC
I've migrated SyncEvolution from libcurl to libsoup as part of integrating it into Moblin. One of the long-standing issues was that SSL verification wasn't enabled due to not setting a CA file:

Now I have the CA file, but it fails to verify

Google uses a certificate signd by Thawte, which is signed by Verisign. With libcurl-gnutls and in Firefox this peer is accepted.

I compiled libsoup 2.26.3 and gnutls 2.4.2 (Ubunty Jaunty) from source and traced it down to this check here:

  • #0 _gnutls_verify_certificate2
    at verify.c line 268
  • #1 _gnutls_x509_verify_certificate
    at verify.c line 385
  • #2 gnutls_x509_crt_list_verify
    at verify.c line 782
  • #3 _gnutls_x509_cert_verify_peers
    at gnutls_x509.c line 176
  • #4 gnutls_certificate_verify_peers2
    at gnutls_cert.c line 606
  • #5 gnutls_certificate_verify_peers
    at gnutls_cert.c line 639
  • #6 verify_certificate
    at soup-gnutls.c line 64
  • #7 do_handshake
    at soup-gnutls.c line 167

(gdb) list
263       if (!(flags & GNUTLS_VERIFY_DISABLE_CA_SIGN) &&
264           !((flags & GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) && issuer_version == 1))
265         {
266           if (check_if_ca (cert, issuer, flags) == 0)
267             {
268               gnutls_assert ();
269               if (output)
270                 *output |= GNUTLS_CERT_SIGNER_NOT_CA | GNUTLS_CERT_INVALID;
271               return 0;
272             }

libsoup does not pass any flags, so  check_if_ca() is called and fails. libcurl passes flags = 2 = GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT, so this check is skipped.

There are some discussions around that flags which might be relevant:

The Verisign root certificate indeed seems to be version 1, so at first glance everything seems to work as intended... except that this is not particularly useful. As long as Google doesn't get a different certificate from Verisign, the only fallback is using plain http.

What is the recommendation for handling this problem? Educate users that SSL with Google is not secure and therefore has to be rejected or somehow set the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT flag? How?
Comment 1 Patrick Ohly 2009-07-23 14:14:55 UTC
Created attachment 139077 [details] [review]
minor fix: check that gnutls_certificate_allocate_credentials() really succeeded
Comment 2 Patrick Ohly 2009-07-23 14:16:32 UTC
Created attachment 139078 [details] [review]

As discussed with Dan on IRC, setting the flag should be safe because the CA certs file is meant to contain only CA certificates.

This patch depends on the other one. Both are against gnome-2-26.
Comment 3 Dan Winship 2009-07-23 19:42:59 UTC
the irc conversation:

<danw> the problem they describe with V1 certs shouldn't apply to libsoup, because libsoup only lets you specify CA certs, not host/people certs, so the problem of not being able to distinguish CA certs from host certs can't possibly come up
<danw> so it should be safe for us to pass the flag you mentioned
<pohly> danw: are you sure? What if the CA certificate file that is passed by the app contains both CA root certificates as well as host/people certs? Isn't that possible with the current API?
<pohly> I'm talking about the client here.
<danw> well... the documentation says that the file is supposed to contain CA certs, so if you pass a file containing non-CA certs it's undefined :)
<pohly> Fair enough ;-)

I'm not going to worry about the possibility of allocate_credentials() failing, because if it fails, then the next glib-based allocation will fail too, and that will cause an abort(). Given that, the other patch didn't apply cleanly, and I didn't want the huge comment in there anyway, so I just replaced it with a reference to this bug.

committed and pushed. thanks for the fix.