Bug 503074 - Pidgin does not accept Twitter new certificate
Pidgin does not accept Twitter new certificate
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: pidgin (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
Fedora Extras Quality Assurance
:
: 503105 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-28 13:41 EDT by Mauricio Teixeira
Modified: 2009-06-18 14:22 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-05 13:37:40 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)
Equifax Secure Global eBusiness CA-1 cert (949 bytes, text/plain)
2009-06-02 17:11 EDT, Mauricio Teixeira
no flags Details

  None (edit)
Description Mauricio Teixeira 2009-05-28 13:41:30 EDT
Twitter seems to have issued a new SSL certificate at Jun/26. Since yesterday my Pidgin started complaining about invalid certificate from twitter.com

(12:01:57) proxy: Attempting connection to 128.121.146.100
(12:01:57) proxy: Connecting to twitter.com:443 with no proxy
(12:01:57) proxy: Connection in progress
(12:01:58) proxy: Connecting to twitter.com:443.
(12:02:01) nss: subject=CN=twitter.com,OU=Domain Control Validated - RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)08,OU=GT09721236,O=twitter.com,C=US issuer=CN=Equifax Secure Global eBusiness CA-1,O=Equifax Secure Inc.,C=US
(12:02:01) nss: partial certificate chain
(12:02:01) certificate/x509/tls_cached: Starting verify for twitter.com
(12:02:01) certificate/x509/tls_cached: Checking for cached cert...
(12:02:01) certificate/x509/tls_cached: ...Found cached cert
(12:02:01) nss/x509: Loading certificate from /home/mteixeir/.purple/certificates/x509/tls_peers/twitter.com
(12:02:01) certificate/x509/tls_cached: Peer cert did NOT match cached
(12:02:01) certificate: Checking signature chain for uid=CN=twitter.com,OU=Domain Control Validated - RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)08,OU=GT09721236,O=twitter.com,C=US
(12:02:01) certificate: ...Singleton. We'll say it's valid.
(12:02:01) certificate/x509/tls_cached: Checking for a CA with DN=CN=Equifax Secure Global eBusiness CA-1,O=Equifax Secure Inc.,C=US
(12:02:01) certificate/x509/tls_cached: Certificate Authority with DN='CN=Equifax Secure Global eBusiness CA-1,O=Equifax Secure Inc.,C=US' not found. I'll prompt the user, I guess.

I get a pop up asking if I want to accept, I say yes, then it works for a few minutes (20/30, not sure) then it asks to confirm the cert again.

Removing the cached file and restarting does not fix.
Comment 1 Warren Togami 2009-05-28 15:29:29 EDT
Please file bugs against plugins to the specific package those plugins come from.  This is not a pidgin bug.
Comment 2 Mauricio Teixeira 2009-05-28 15:34:45 EDT
Reported upstream, as requested by Warren.

http://code.google.com/p/microblog-purple/issues/detail?id=108
Comment 3 Warren Togami 2009-05-28 17:16:25 EDT
*** Bug 503105 has been marked as a duplicate of this bug. ***
Comment 4 Mauricio Teixeira 2009-06-01 16:58:17 EDT
I followed instructions here: http://developer.pidgin.im/ticket/9264#comment:3

Adding the new .pem file into /usr/share/purple/ca-certs fixes the issue.

So, it's not a bug in the plugin, just a missing root certificate on the main pidgin package (that is delivered from the libpurple package).

Please consider the proposed fix. Thank you.
Comment 5 Steevithak 2009-06-02 13:06:06 EDT
I'm experiencing this bug too. It's a bit frustrating as both upstream bugs seem to have been closed with won't fix, each blaming the other group of developers.

The Pidgin folks say, "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."

 http://developer.pidgin.im/ticket/9264

Meanwhile, the twitter plugin developers say, "I'll change status to WontFix, since it seems to be Pidgin (Purple) problems."

 http://code.google.com/p/microblog-purple/issues/detail?id=23

Later comments suggest there is no problem on Ubuntu and the plugin developers are going to provide a fix for Windows. But it looks like Fedora users are out of luck unless somebody upstream adds a missing certificate.
Comment 6 Warren Togami 2009-06-02 13:47:16 EDT
Then figure out what certificate is missing and submit a patch to the appropriate party.
Comment 7 Ismael Olea 2009-06-02 17:04:38 EDT
I don't know which cert is exactly needed. The thing is I've just made a handmade experiment:

[olea@lisergia ~]$ ls -l /usr/share/purple/ca-certs
lrwxrwxrwx 1 root root 18 jun  2 22:44 /usr/share/purple/ca-certs -> /etc/pki/tls/certs


I didn't move any libpurple packaged cert into it and now seems to run very smoothly. Only asked for some obvius MSN's certificate.

My suggestion then would be:

 * modify the certificates root directory in libpurple to take use of /etc/pki/tls/certs
 * install the present certificates from /usr/share/purple/ca-certs to /etc/pki/tls/certs

and hopefully the problem should be solved.

Anybody knows some policy against this?
Comment 8 Mauricio Teixeira 2009-06-02 17:11:06 EDT
Created attachment 346318 [details]
Equifax Secure Global eBusiness CA-1 cert

This is the CA that needs to be copied under /usr/share/purple/ca-certs. To me it does not matter if that will be shipped from libpurple or the pidgin-microblog plugin package. The point is upstream Pidgin developer is not interested in adding this cert (or at least does not seem willing to do so) and this file needs to go somewhere to fix this ticket.
Comment 9 Ismael Olea 2009-06-02 17:20:03 EDT
Addenda:

 * probably should be added a libpurple  dependency on ca-certificates, which
contents  /etc/pki/tls/certs/ca-bundle.crt
Comment 10 Ismael Olea 2009-06-02 17:28:06 EDT
(In reply to comment #8)
> Created an attachment (id=346318) [details]
> Equifax CA cert
> 
> This is the CA that needs to be copied under /usr/share/purple/ca-certs. To me
> it does not matter if that will be shipped from libpurple or the
> pidgin-microblog plugin package. The point is upstream Pidgin developer is not
> interested in adding this cert (or at least does not seem willing to do so) and
> this file needs to go somewhere to fix this ticket.  


btw, I tried this first and really didn't work. I've not got the error messages but it was continously asking for approvals.

If you are kind enough, please try my trick too. If we feel this is working I would strongly suggest to consolidate all certs at /etc/pki/tls/certs, again: if there is not policy against it.
Comment 11 Mauricio Teixeira 2009-06-03 07:35:24 EDT
Sorry, the link to /etc did not work for me. Using the provided PEM file on standard ca-certs directory works fine.
Comment 12 Matěj Cepl 2009-06-05 10:50:15 EDT
(In reply to comment #9)
> Addenda:
> 
>  * probably should be added a libpurple  dependency on ca-certificates, which
> contents  /etc/pki/tls/certs/ca-bundle.crt  

Right you are. Reassigning the bug to proper component. It seems to me that this certificate is present in /etc/pki/tls/certs/ca-bundle.crt, but I would let it be judged by more competent developers.
Comment 13 Joe Orton 2009-06-05 11:14:54 EDT
Why have you reassigned this bug?  The cert listed above:

    Issuer: C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1

appears to be present in ca-bundle.crt as you say.
Comment 14 Matěj Cepl 2009-06-05 13:20:24 EDT
(In reply to comment #13)
> Why have you reassigned this bug?  The cert listed above:
> 
>     Issuer: C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness
> CA-1
> 
> appears to be present in ca-bundle.crt as you say.  

I was wrong, of course, libpurple doesn't care about system-wide certs. Hmm, that however opens another question. Why does libpurple not care about them? Warren? 

And yes certificate attached here as attachment 346318 [details] is not present in /usr/share/purple/ca-certs as provided by libpurple, so the temporary workaround would be to add it there.

But I think the proper solution is to make pidgin use system wide certs.
Comment 15 Matěj Cepl 2009-06-05 13:25:15 EDT
Comment on attachment 346318 [details]
Equifax Secure Global eBusiness CA-1 cert

Just to emphasize that this is not "Equifax Secure Certificate Authority" certificate (which is present in libpurple), but "Equifax Secure Global eBusiness CA-1" one, which isn't.
Comment 16 Matěj Cepl 2009-06-05 13:37:40 EDT
OK, after re-reading http://developer.pidgin.im/ticket/9264 especially sentence (part in the second parenthesis):

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).

I don't there is other solution than to persuade libpurple maintainers to include the certificate in question to their set of certs.

Closing as UPSTREAM
Comment 17 Steevithak 2009-06-18 14:22:08 EDT
FWIW, confirming that this bug still existing on F11 with Pidgin/Libpurple 2.5.6-1.

Note You need to log in before you can comment on or make changes to this bug.