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.
Please file bugs against plugins to the specific package those plugins come from. This is not a pidgin bug.
Reported upstream, as requested by Warren. http://code.google.com/p/microblog-purple/issues/detail?id=108
*** Bug 503105 has been marked as a duplicate of this bug. ***
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.
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.
Then figure out what certificate is missing and submit a patch to the appropriate party.
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?
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.
Addenda: * probably should be added a libpurple dependency on ca-certificates, which contents /etc/pki/tls/certs/ca-bundle.crt
(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.
Sorry, the link to /etc did not work for me. Using the provided PEM file on standard ca-certs directory works fine.
(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.
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.
(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 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.
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
FWIW, confirming that this bug still existing on F11 with Pidgin/Libpurple 2.5.6-1.