Opened 10 years ago

Closed 10 years ago

#9264 closed enhancement (fixed)

New twitter.com SSL certificate root server unrecognized

Reported by: zxinn Owned by: lschiere
Milestone: 2.6.0 Component: libpurple
Version: 2.5.6 Keywords: twitter mbpurple certificate ssl microblog
Cc: projekt21, bazzargh

Description

I'm using the latest microblog-purple (0.2.1), with the latest Pidgin (2.5.6). http://code.google.com/p/microblog-purple/

I'm getting very many messages about twitter's certificate (the connection to twitter is very erratic at times).

"The root certificate this one claims to be issued by is unknown to Pidgin."

From the basic info about the certificate in Pidgin (certifiacte file will be included):

Common name: twitter.com

Fingerprint (SHA1): 9e:e9:97:20:1b:d2:17:cb:cc:0c:8f:19:42:75:2d:6b:ac:07:e1:93

Activation date: Tue May 26 21:34:48 2009

Expiration date: Fri May 28 18:58:13 2010

Attachments (5)

twitter_cert_26may2009.pem (1.2 KB) - added by zxinn 10 years ago.
twitter.com SSL certificate, issued May 26th 2009
EquifaxSecureGlobaleBusinessCA-1.crt (964 bytes) - added by bazzargh 10 years ago.
"Equifax Secure Global eBusiness CA-1" cert, pem format
test.log (4.5 KB) - added by bazzargh 10 years ago.
log showing twitter cert being verified
pidgin-1.log (3.9 KB) - added by projekt21 10 years ago.
pidgin log file (relevant section)
twitter2.com (1.2 KB) - added by bazzargh 10 years ago.
the certificate with fingerprint 2b:66:47:fe:49:7d:f1:52:96:d2:42:29:cb:cb:5d:b1:db:a1:e4:fb

Download all attachments as: .zip

Change History (24)

Changed 10 years ago by zxinn

twitter.com SSL certificate, issued May 26th 2009

comment:1 Changed 10 years ago by rekkanoryo

  • Resolution set to invalid
  • Status changed from new to closed

This issue is caused by a third party plugin. We have no control over these plugins. Please report this problem to the authors of this third party plugin.

The authors of the plugin will need to supply the appropriate certificates with the plugin.

comment:2 Changed 10 years ago by projekt21

Could this be reopened, because the problem might be within pidgin? twitter.com currently sends two valid certificates. If you accept one, the other one will prompt soon after. Does pidgin support multiple certificates for the same server? According to http://1n73r.net/2008/10/14/pidgin-gtalk-certificate this might happen elsewhere (gtalk), too.

Changed 10 years ago by bazzargh

"Equifax Secure Global eBusiness CA-1" cert, pem format

comment:3 follow-up: Changed 10 years ago by bazzargh

The problem is that pidgin ships on some platforms with a relatively incomplete set of root CA certificates. On platforms where pidgin is built with system-certificate support, a more comprehensive set is available; but on windows, only the pidgin-supplied root CAs are used.

This same problem also affects the facebook plugin (and it's the same root CA that's missing, apparently). I've attached the copy of the missing root CA cert I used to fix the problem for myself - by exporting it from firefox, and adding it into C:\Program Files\Pidgin\ca-certs\EquifaxSecureGlobaleBusinessCA-1.pem ; posting this info for people who find themselves reading this bug. It'd be a good idea for you to export the certificate from firefox yourself, rather than use the attached copy however.

comment:4 Changed 10 years ago by projekt21

Works, but now I am getting: "Invalid certificate authority signature

The certificate chain presented by twitter.com does not have a valid digital signature from the Certificate Authority from which it claims to have a signature.".

Any hint?

comment:5 Changed 10 years ago by bazzargh

projekt21: can you be a bit clearer what you tried here. Are you saying you added the twitter cert or the equifax cert? And are you using the latest pidgin/mbpurple? On what platform? Also, which certificate is it complaining about - I see two from twitter, the problematic one (for which pidgin had no CA cert) had signature: 2b:66:47:fe:49:7d:f1:52:96:d2:42:29:cb:cb:5d:b1:db:a1:e4:fb

I just tried this again, removing my cached certificates in case that was masking your problem. Those are stored in: C:\Documents and Settings\<user>\Application Data\.purple\certificates\x509\tls_peers\

I then restarted pidgin using 'pidgin -d > debug.log', am attaching the relevant section showing the twitter cert being verified.

Changed 10 years ago by bazzargh

log showing twitter cert being verified

comment:6 Changed 10 years ago by projekt21

Yes, sorry. I followed your instructions: exported EquifaxSecureGlobaleBusinessCA-1.pem from current Firefox and saved it in /usr/local/share/purple/ca-certs/ (it's identical to your attached file). I'm using the latest versions of Pidgin and mbpurple on SUSE 10.3.

I attached the relevant section from my log.

Changed 10 years ago by projekt21

pidgin log file (relevant section)

comment:7 Changed 10 years ago by bazzargh

projekt21: Its possible that your problem is related to bug 4458 http://developer.pidgin.im/ticket/4458

...since I'm using nss, not gnutls, that wouldn't affect me. If you get asked about the cert with fingerprint 2b:66:47:fe.... again can you say 'yes', grab it from your cache, and upload it? As you comment above, pidgin is storing certs with their server name, not (eg) with their fingerprint, so if there really are two certs being presented here it only stores one; and I see I have the 9e:e9:... key stored (this isn't obvious, because nss doesn't put the fingerprints into the log). I've been trying to test this with

openssl s_client -connect twitter.com:443 -CApath ca -showcerts </dev/null

(under cygwin, and 'ca' here is a copy of my pidgin ca-cert dir after I've run 'c_rehash ca' on it to make it usable by openssl), wondering if one set of twitter's servers use a different cert, since both are in your log fragment as being twitter.com, but I keep seeing the one 9e:e9:... cert.

comment:8 Changed 10 years ago by projekt21

Since I installed EquifaxSecureGlobaleBusinessCA-1.pem I am never again asked to accept anything. I get the above message instead. And yes, there are two certs and both are valid. I have no idea if the bugs are related, but I will dig into this.

Changed 10 years ago by bazzargh

the certificate with fingerprint 2b:66:47:fe:49:7d:f1:52:96:d2:42:29:cb:cb:5d:b1:db:a1:e4:fb

comment:9 Changed 10 years ago by bazzargh

After removing the CA cert again I managed to capture the alternate 2b:66 cert being presented (attached above). Sure enough, its 'Signature Algorithm: md5WithRSAEncryption', So bug 4458 applies. However, twitter probably shouldn't be using this cert. I'll ask @twitterapi.

comment:10 follow-up: Changed 10 years ago by darkrain42

We have no interest in maintaining a full set of root certificates; the current ones are the ones needed by the various protocols distributed with pidgin.

Third-party plugins are free to install certificates into the appropriate folder (which you have already discovered) as needed (although, like the extensions, the Pidgin installer unfortunately overwrites them when updating to a new version).

The only aspect of this issue that I believe is actually a Pidgin bug appears to be a duplicate of #4458.

comment:11 Changed 10 years ago by projekt21

I have recompiled pidgin and mbpurple with NSS and haven't got any further alerts so far. So:

  • install EquifaxSecureGlobaleBusinessCA-1.pem into ca-certs
  • use pidgin with NSS

fixes this problem. I second darkrain42, mbpurple should install EquifaxSecureGlobaleBusinessCA-1.pem and recommend NSS until #4458 is fixed.

comment:12 follow-up: Changed 10 years ago by bazzargh

darkrain42: mostly I agree. I am just posting info on this bug to help people who actually have to deal with it - I've not asked for it to be reopened.

However, I'd add that I consider the cert cache using filenames based on the hostname rather than the fingerprint to be a pidgin bug. It means that the plugins have to install a ca-cert rather than just add the appropriate server cert into the cache, to deal with servers (like twitters) that use multiple certs.

comment:13 in reply to: ↑ 12 Changed 10 years ago by darkrain42

Replying to bazzargh:

However, I'd add that I consider the cert cache using filenames based on the hostname rather than the fingerprint to be a pidgin bug. It means that the plugins have to install a ca-cert rather than just add the appropriate server cert into the cache, to deal with servers (like twitters) that use multiple certs.

While I do think it's probably reasonable to want to cache more than one certificate per host (which would likely require a per-fingerprint storage mechanism), it's absolutely not a good reason to do so to "make it easier" for plugins to distribute a set of specific server certificates instead of adding the trusted roots (and intermediate CAs) as necessary. That defeats the whole purpose of x509 trust chains and, if servers have multiple certificates on load-balanced servers, is a silly (and incredibly error-prone) way to ensure that the certificates for all of the servers are trusted.

Moreover (I haven't confirmed this), I believe the trusted certificate cache is per-user, whereas plugins like this are typically installed system-wide.

comment:14 in reply to: ↑ 3 Changed 10 years ago by medians

Replying to bazzargh:

The problem is that pidgin ships on some platforms with a relatively incomplete set of root CA certificates. On platforms where pidgin is built with system-certificate support, a more comprehensive set is available; but on windows, only the pidgin-supplied root CAs are used.

This same problem also affects the facebook plugin (and it's the same root CA that's missing, apparently). I've attached the copy of the missing root CA cert I used to fix the problem for myself - by exporting it from firefox, and adding it into C:\Program Files\Pidgin\ca-certs\EquifaxSecureGlobaleBusinessCA-1.pem ; posting this info for people who find themselves reading this bug. It'd be a good idea for you to export the certificate from firefox yourself, rather than use the attached copy however.

I'm still not sure how to export this file, and where exactly to put it, if I were even able to. The new certificate attachment isn't really even a file, available for download, but a link to a page in the Pidgin web page (as I'm sure you're well aware). I'm hardly a techy, so this all kind of looks like programmer jargon to me. Ha.

Could you walk me through exactly what it takes to fix this bug, and in plain English, step by step? Otherwise, I don't think I'll ever figure this out. Or, if you're involved in developing mbpurple, just release an update that has this bug already smoothed out. :)

comment:15 Changed 10 years ago by bazzargh

medians: if you're not on Windows, and not techy, you're not going to be able to use this workaround - pidgin needs to be built with the 'nss' library for the solution to work and on linux it often isn't; if you need help beyond this please contact the pidgin support list. No, I don't develop mbpurple or pidign.

Attachments can be downloaded from their pages: look at the bottom of the page and it says 'Download in original format'.

To export from Firefox: open preferences, choose 'Advanced', under that select 'Encryption', and click 'View Certificates'. This opens the 'Certificate Manager' dialog. Now choose 'Authorities' (these are the 'CA' certificates we've been discussing). Scroll down through this list until you reach 'Equifax Secure Inc' - you should see the 'Equifax Secure Global eBusiness CA-1' listed there. Select that and click 'export' and choose the format 'X.509 Certificate (PEM)'.

Either way you obtain the certificate, save it in C:\Program Files\Pidgin\ca-certs\EquifaxSecureGlobaleBusinessCA-1.pem as I mentioned above.

Hope this helps.

comment:16 Changed 10 years ago by nosnilmot

  • Resolution invalid deleted
  • Status changed from closed to new

comment:17 in reply to: ↑ 10 Changed 10 years ago by nosnilmot

Replying to darkrain42:

We have no interest in maintaining a full set of root certificates; the current ones are the ones needed by the various protocols distributed with pidgin.

We support XMPP, therefore we should support SSL certs that might be issued to XMPP servers. Unfortunately this means quite a lot of them. We should probably include the root CA here.

Third-party plugins are free to install certificates into the appropriate folder (which you have already discovered) as needed.

While true, I would not want to advocate this.

comment:18 Changed 10 years ago by steevithak

I just upgraded from Redhat Fedora 10 to 11 and can confirm this bug still exists with the Pidgin/libpurple 2.5.6-1 included in the new distro. The equivalent bug has been closed in Redhat's bugzilla with this statement,

"I don't [think] there is [any] other solution than to persuade libpurple maintainers to include the certificate in question to their set of certs. Closing as UPSTREAM"

https://bugzilla.redhat.com/show_bug.cgi?id=503074

comment:19 Changed 10 years ago by darkrain42

  • Component changed from unclassified to libpurple
  • Milestone set to 2.6.0
  • Resolution set to fixed
  • Status changed from new to closed

I'm pretty sure I typoed the commit glue, but this will be in 2.6.0

In 13ea852ce32b51825f2eed8e544a06ddd32bf698: Add the twitter.com CA cert. Fixes 9264.

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!