Note there's even another issue lingering here.

The legacy CA this server is chaining to, has been kept as a legacy CA, because it's using a 1024-bit RSA key.

In the meantime, Mozilla has decided to completely remove this root for any purpose, because it's no longer included in published audit statements
(see number 4 in https://bugzilla.mozilla.org/show_bug.cgi?id=1288250 )

Because of that, I've intended to completely remove those, even remove them from the legacy CA list 2.10, for all supported versions of Fedora, as part of the most recent CA list update (published as part of NSS 3.27).

(I think I'll have to use a longer testing phase for the ca-certificates 2.10 update, to see how much it would break.)

Brian, how can we reach the developers that maintain the certificate validation inside this software? Do you have contacts?

F24 is affected too.

With ca-certificates-2016.2.10-1.0.fc24.noarch arrived a couple of days ago telepathy started to complain about the certificate being self-signed (which is confusing because it pops up a dialog with gmail.com certificate signed by Google Internet Authority G2, and it takes quite an effort to figure out that in reality it can't verify Equifax' signature on GeoTrust's certificate).

On a quick check Google seems to include this certificate on other services, too: https://www.google.com/, imaps://imap.gmail.com/, etc.  Only telepathy-gabble broke with removal of Equifax certificates, though.

The problem is that the server uses a compatibility configuration, which requires client software to be smart, and be able to find an alternative chain of trust.

I have explained the background here:
https://rt.openssl.org/Ticket/Display.html?id=3621#txn-49999

It's the client software that is broken and incompatible with modern requirements.

The developers of the broken software should switch to better certificate verification code (and preferably not implement this part on their own, but rather use standard code from a SSL/TLS library).

*** Bug 1385539 has been marked as a duplicate of this bug. ***

I'm not sure we have the right component. I see in the empathy debug window:
empathyTls-DEBUG: 10/19/2016 09:44:07.79547: perform_verification: Performing verification
empathyTls-DEBUG: 10/19/2016 09:44:07.79591: debug_certificate_chain: Certificate chain: length 3 status incomplete
empathyTls-DEBUG: 10/19/2016 09:44:07.79890: debug_certificate: Certificate: C=US, ST=California, L=Mountain View, O=Google Inc, CN=gmail.com
empathyTls-DEBUG: 10/19/2016 09:44:07.80071: debug_certificate: Certificate: C=US, O=Google Inc, CN=Google Internet Authority G2
empathyTls-DEBUG: 10/19/2016 09:44:07.80249: debug_certificate: Certificate: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
empathyTls-DEBUG: 10/19/2016 09:44:07.80549: perform_verification: Certificate verification gave result 0 with reason 6
empathyTls-DEBUG: 10/19/2016 09:44:07.80606: abort_verification: Verification error 6, aborting...


but I can find no trace of these debug messages at telepathy-gabble (which seems to not use the system certificates for verification -though its verification code is ok).

The issue seems to be in empathy itself perform_verification_cb() and perform_verification(), which attempts to create the trust chain.

OK the problem is not in empathy but in gcr,
gcr/gcr-certificate-chain.c:perform_build_chain() which is the main worker in

...
  empathy_tls_verifier_verify_async
    gcr_certificate_chain_build_async
      thread_build_chain
        perform_build_chain


perform_build_chain() traverses the certificate chain passed in by the caller and looks up the certificate *itself* among pkcs11 anchors, and only looks up the issuer of the last certificate in the chain.

Apparently it should rather look up the issuer of the current certificate first, and, if found, stop the chain traversal.

Can someone with the rights please adjust the component?

Roman, thanks a lot for your research. Changing component.

However it is unclear whether gcr needs to perform its own certificate validation - why doesn't it delegate this job to gnutls?

> However it is unclear whether gcr needs to perform its own certificate validation - why doesn't it delegate this job to gnutls?

It certainly should. The certificate assembly and validation in GCR predates PKCS#11 support in GnuTLS. GCR and/or its callers should be migrated to use the latter now.

Does this mean GCR should pick up a dependency on GnuTLS?

It already links to libp11-kit. Can p11-kit do this, too?

Nah, p11-kit isn't about TLS. GnuTLS uses p11-kit to load certificates and keys, but p11-kit doesn't know how they'll be chained, assembled, used or verified.

I spoke too hastily above though. glib-networking is the thing that has the multiple TLS backends and the GnuTLS dependency ... it also has custom certificate validation code that predates GnuTLS working with PKCS#11.

Gcr custom chain code should be removed and glib-networking's custom certificate chain code implemented using GnuTLS.

I think glib-networking was already changed to use the validation code from GnuTLS. If gcr already has a dependency on glib-networking (does it?), then maybe gcr could reuse the glib-networking code that uses GnuTLS?

Adding Dan, who has worked in this area.

If that's the case, that's great.

I wonder what callers actually use the Gcr code, if any. We may be able to just remove those APIs in favor of glib-networking. The Gcr API is marked as unstable, so with API removal ... along with some patches to known API callers ... I think we would be in good shape.

glib-networking uses gnutls's validation code by default, but currently still uses the broken internal code when using PKCS#11. See https://bugzilla.gnome.org/show_bug.cgi?id=753260#c9

I'm hitting this issue... any workaround?

Looks like this bug fell through the gaps between maintainers' responsibility zones...

Has it been decided what needs to be done?  Is anybody working on this?

Comment 15 links to the upstream bug that shows what needs to be done. So it's not fixed upstream yet, so there's nothing Fedora maintainers can do. (And it's not being worked on upstream, so there's no ETA, though if you want to try to dive in and tackle it, the upstream bug shows what needs to be done and I can at least help out with review/questions.)

Sorry, my previous comment is wrong; I should have re-read the whole bug. The main bug here is that empathy/gcr needs to be ported to use glib-networking to do its certificate validation. Once that is done, the bug here will be fixed for basically everyone. The upstream glib-networking bug is only relevant to people using PKCS#11, and only relevant *after* empathy/gcr is changed to actually use glib-networking's code.

(In reply to Stef Walter from comment #14)
> I wonder what callers actually use the Gcr code, if any. We may be able to
> just remove those APIs in favor of glib-networking. The Gcr API is marked as
> unstable, so with API removal ... along with some patches to known API
> callers ... I think we would be in good shape.

Yes, let's do that. In this particular case, we can teach empathy to just use the GIO / glib-networking API instead of Gcr.

Reassigning.

Reassigning to myself (again).

For those interested, patches at:
https://bugzilla.gnome.org/show_bug.cgi?id=780160

empathy-3.12.13-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bd15ca5490

empathy-3.12.13-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8840ec0204

Everyone affected by this bug, could you please test the package, and give us feedback? Thanks in advance

empathy-3.12.13-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bd15ca5490

Guys, how to test this?

when I run:

sudo dnf --enablerepo=updates-testing check-update  | grep empathy

I get no output on f25

Paolo, maybe it was too early, and the update had not yet reached the download servers. Can you try again? Or alternatively, if you don't want to wait, on the bodhi page, you can click download the build manually. Upper left, "Builds", circle/arrow icon, find rpm for your platform, download, install with rpm -U.

empathy-3.12.13-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8840ec0204

Tested and working fine for me on f25

sudo dnf install https://kojipkgs.fedoraproject.org//packages/empathy/3.12.13/2.fc25/x86_64/empathy-3.12.13-2.fc25.x86_64.rpm

Thank you!

Tested and working fine for me on f25

sudo dnf install https://kojipkgs.fedoraproject.org//packages/empathy/3.12.13/2.fc25/x86_64/empathy-3.12.13-2.fc25.x86_64.rpm

Thank you!

empathy-3.12.13-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

empathy-3.12.13-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.