Opened 6 years ago

Last modified 4 years ago

#15486 new defect

pidgin/purple fails with "The certificate chain presented is invalid."

Reported by: calestyo Owned by:
Milestone: Component: libpurple
Version: 2.10.6 Keywords:
Cc: peter.meier, moehrenfeld, chr.istoph, muriloq



Typically, when pidgin/purple gets a server cert which it cannot validate it asks me whether I want to accept or reject it.

I have a case, where my ejabberd sends a certificate (+ its chain) but pidgin complains with:

Unable to validate certificate

The certificate for could not be validated. The >certificate chain presented is invalid.

But the certificate chain looks perfectly.

One such and example chain is attached, as it is configured in my ejabberd (same order of the certs, the key obviously missing ;) )

Any ideas?


Attachments (1)

chain (7.2 KB) - added by calestyo 6 years ago.
certificate chain

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by calestyo

certificate chain

comment:1 Changed 6 years ago by ans

i'd like to confirm this bug. it affects several of our users, but we are currently unable to determine the cause. for example several ubuntu 10.04 users are affected, however a fresh installation i set up did not exhibit the problem. it might be a side effect of another installed package. it is however not a configuration issue since it persists after removing .purple. this also affects version 2.10.3. as a workaround the leaf certificate can be manually imported in pidgin.

our server is an ejabberd as well, running at the affected users have the cacert root-cert installed and are able to correctly verify the same certificate using chrome which also uses libnss (s.

the following debug output is produced by pidgin failing to validate the cert:

(08:57:32) certificate/x509/tls_cached: Starting verify for
(08:57:32) certificate/x509/tls_cached: Checking for cached cert...
(08:57:32) certificate/x509/tls_cached: ...Not in cache
(08:57:32) certificate: Checking signature chain for
(08:57:32) certificate: ...Good signature by CN=CAcert Class 3 Root,OU=,O=CAcert Inc.
(08:57:32) certificate: ...Bad or missing signature by,CN=CA Cert Signing Authority,OU=,O=Root CA
Chain is INVALID
(08:57:32) certificate: Failed to verify certificate for

the certificate is definitely ok, see e.g.:

openssl s_client -CAfile class3.crt -connect | grep return
depth=2 O = Root CA, OU =, CN = CA Cert Signing Authority, emailAddress =
verify return:1
depth=1 O = CAcert Inc., OU =, CN = CAcert Class 3 Root
verify return:1
depth=0 CN =
verify return:1
    Verify return code: 0 (ok)

if you need more information please write so. we have now access to an affected installation.

comment:2 Changed 6 years ago by peter.meier

For me it does not work on a latest ubuntu version.

As the former comment mentioned: Importing cert manually fixes the problem. Every other software on the system validates the certs perfectly.

comment:3 Changed 6 years ago by ans

some more anecdotal evidence that the problem exists in the wild:

@purple_devs can you please comment if you have this on the radar, so i can stop spamming this thread ;)

comment:4 Changed 6 years ago by peter.meier

So the problem is the following:

Pidgin still has the *old* class 3 certificate from using md5 as signing algorithm in its source:

$ curl -s | openssl x509 -text | grep Signature
        Signature Algorithm: md5WithRSAEncryption
    Signature Algorithm: md5WithRSAEncryption

However, there is a new version of this certificate avaiable using sha256 as signing algorithm:

$ curl -s| openssl x509 -text | grep Signature        Signature Algorithm: sha256WithRSAEncryption
    Signature Algorithm: sha256WithRSAEncryption

This is a problem, as Mozilla NSS disabled support for MD5 hash signed certificates in the 3.14 release and this (or newer) release is common in modern distributions (even RedHat? Enterprise Linux 6.4 now ships a version that doesn't support md5 hash signed certificates anymore )

So any modern distribution that should verify a certificate signed with the class 3 cert of cacert, will fail, especially recent signed certificates.

You should fix this issue by updating the vendored class3 certificate (share/ca-certs/CAcert_Class3.pem) to the latest available one on ->

comment:5 Changed 6 years ago by peter.meier

Please note, that the jabber server on (Port 5223) provides the full certificate chain, including the class3 certificate of, but pidign/libnss still takes the bundled one and hence fails to verify.

This is maybe also something that you should fix.

comment:6 Changed 6 years ago by datallah

I don't see the behavior you're describing with using nss 3.14.3 (it works fine for me).

comment:7 Changed 6 years ago by moehrenfeld


I have the same problem with pidgin 2.10.6-0ubuntu2 under Linux Mint. I was unsuccessful in fixing the problem. I had to manually replace the certificate under .purple/certificates/x509/tls_peers/ to make Pidgin reconnect to the server.

I also use CAcert and just renewed my server certificate.

comment:8 Changed 5 years ago by chr.istoph

I can confirm this bug using the XMPP server at The server certificate is signed by CACert and is accepted as valid by 'openssl verify' and 'vfychain' (libnss3-tools). I have connected to the server using the XMPP client psi, and the certificate is readily accepted. For testing, I rebuilt pidgin with gnutls instead of libnss. This testing version does not show any certificate error anymore.

Last edited 5 years ago by chr.istoph (previous) (diff)

comment:9 Changed 4 years ago by muriloq

This problem also occurs using Pidgin 2.10.10 on Windows 7 64-bit.

comment:10 Changed 4 years ago by muffins

I'm also having this problem with Pidgin 2.10.10 on Windows 8.1 and Debian Jessie, testing.

The server is a pretty new openfire XMPP server. No other clients seem to have the issue.

comment:11 Changed 4 years ago by datallah

Those experiencing this issue after 2.10.10 should look at #16412.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!