Invalid certificate authority signature

[GoogleCodeExporter]

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

What steps will reproduce the problem?
1. when i became online i have the above message

What version of the product are you using? On what operating system?
mbpurple-0.1.2, pidgin-2.4.3

Original issue reported on code.google.com by biru.ionut on 21 Aug 2008 at 9:06

Attachments:

• log

[GoogleCodeExporter]

Which version of Pidgin have you install the plug-in with?

The message never appear for me.

Original comment by somsaks on 21 Aug 2008 at 9:47

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

i mention already. 2.4.3 
also i'm using archlinux and pidgin is compiled against gnutls 2.4.1-1.

Original comment by biru.ionut on 21 Aug 2008 at 10:06

[GoogleCodeExporter]

sorry i red it too quick.

sugree may be able to answer this. AFAIK, he doesn't has this problem with 
Ubuntu 8.04.

Original comment by somsaks on 21 Aug 2008 at 10:59

[GoogleCodeExporter]

It seems you may use proxy or you are behind transparent proxy. Anyway, I'm not 
sure
because I don't have this problem on Ubuntu.

Original comment by sug...@gmail.com on 21 Aug 2008 at 2:18

[GoogleCodeExporter]

i didn't expected from an developer point, that excuse. "in ubuntu works".
there is a problem with gnutls. tested with nss and is working.

Original comment by biru.ionut on 21 Aug 2008 at 5:06

[GoogleCodeExporter]

Thank you for your verification. 

Sugree said that on Ubuntu it's work because he (and also me) don't have any
experience with ArchLinux. So in this case you should know a lot better than 
us. And
it proves to be true too. I'll flag this knowledge and put it somewhere in 
README
just in case.

I'll change status to WontFix, since it seems to be Pidgin (Purple) problems.

Original comment by somsaks on 22 Aug 2008 at 8:13

• Changed state: WontFix

[GoogleCodeExporter]

I am using pidgin 2.5.1 on xubuntu amd64, compile microblog-purple right out of
source, and this error does exist by me, too. and have to uncheck "use https" 
box in
advanced tab.

Original comment by ye.xu....@gmail.com on 13 Oct 2008 at 2:31

[GoogleCodeExporter]

On ubuntu this worked because pidgin uses the system ca certificates package. On
windows, pidgin uses its own, smaller, set of CA certs, and the required CA 
cert is
missing. You can add the appropriate CA cert and the problem goes away.

I've added some more information on the upstream pidgin bug, explaining how to 
fix this:
http://developer.pidgin.im/ticket/9264#comment:3

(I know this bug is closed, and I agree this is an upstream problem, but the 
previous
comments didn't explain why the behaviour is inconsistent and how to fix it)

Original comment by brian.ew...@gmail.com on 28 May 2009 at 1:25

[GoogleCodeExporter]

Issue 108 has been merged into this issue.

Original comment by somsaks on 29 May 2009 at 7:48

[GoogleCodeExporter]

Issue 109 has been merged into this issue.

Original comment by somsaks on 31 May 2009 at 3:24

[GoogleCodeExporter]

Issue 109 has been merged into this issue.

Original comment by somsaks on 31 May 2009 at 3:24

[GoogleCodeExporter]

Issue 110 has been merged into this issue.

Original comment by somsaks on 1 Jun 2009 at 7:08

[GoogleCodeExporter]

As suggested by upstream bug report, we will look for a way to include the new 
CA
certificates into Windows installer.

Original comment by somsaks on 1 Jun 2009 at 7:13

• Changed state: Accepted

[GoogleCodeExporter]

Same problem for me too. Pidgin 2.5.6 (had the problem with 2.5.5 too)

Original comment by mot...@gmail.com on 1 Jun 2009 at 9:03

[GoogleCodeExporter]

The workaround (from the link above)

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. 

Original comment by mot...@gmail.com on 1 Jun 2009 at 9:08

[GoogleCodeExporter]

I'm experiencing this problem too. I'm running Redhat Fedora GNU/Linux 10 and 
Pidgin
2.5.5-1-fc10. If I understand the above comments correctly, this is working ok 
on
Ubuntu GNU/Linux and a fix is in the works for Windows. Is anyone working on a 
fix
for Fedora? 

Also, does the Windows work-around work on Fedora? If so, can someone provide
instructions or a correct path for saving the certificate?

Original comment by steevit...@gmail.com on 2 Jun 2009 at 5:10

[GoogleCodeExporter]

I ran into a similar issue to this with the google talk certificate under ubuntu
8.04.  When I was looking thought the debug logs when the certificate error 
occurred
I saw that it couldn't open 'etc/ssl/certs'.  That looks like a relative path 
lookup
where an absolute one would be preferred.  I found that by issuing a chdir to 
the
root of the filesystem and starting pidgin there, the certificate lookup 
succeeded
and no manual copying was required.  Perhaps this is a bug in pidgin's 
certificate
management libraries?

from home directory (cd /home/xxx/; pidgin -d):

(14:37:31) certificate: Chain is VALID
(14:37:31) certificate/x509/tls_cached: Checking for a CA with DN=OU=Equifax 
Secure
Certificate Authority,O=Equifax,C=US
(14:37:31) certificate/x509/ca: Couldn't open location 'etc/ssl/certs'
(14:37:31) certificate/x509/ca: Lazy init completed.
(14:37:31) certificate/x509/tls_cached: Certificate Authority with 
DN='OU=Equifax
Secure Certificate Authority,O=Equifax,C=US' not found. I'll prompt the user, I 
guess.

from / (cd /; pidgin -d):

(14:41:30) certificate: Chain is VALID
(14:41:30) certificate/x509/tls_cached: Checking for a CA with DN=OU=Equifax 
Secure
Certificate Authority,O=Equifax,C=US
... snip ...
(14:41:30) nss/x509: Loading certificate from 
etc/ssl/certs/Equifax_Secure_CA.pem
(14:41:30) certificate/x509/ca: Loaded etc/ssl/certs/Equifax_Secure_CA.pem
... snip ...
(14:41:30) certificate/x509/ca: Lazy init completed.
(14:41:30) nss/x509: Exporting certificate to
/home/xxx/.purple/certificates/x509/tls_peers/talk.google.com
(14:41:30) util: Writing file
/home/xxx/.purple/certificates/x509/tls_peers/talk.google.com
(14:41:30) certificate: Successfully verified certificate for talk.google.com

Original comment by samuel.h...@gmail.com on 2 Jun 2009 at 9:52

[GoogleCodeExporter]

sorry, guys, but this workaround is not working with me:

Windows XP Professional, SP3
Pidgin 2.5.6
microblog-purple v 0.2.1

I hope you can fix it soon.

best regards

Original comment by hector.v...@gmail.com on 8 Jun 2009 at 4:38

[GoogleCodeExporter]

Hector --

Make sure that when you export the file, you save it as
EquifaxSecureGlobaleBusinessCA-1.pem, not EquifaxSecureGlobaleBusinessCA-1.crt 
(which
is the default file extension). You have to change the file name so the 
extension is
.pem or else Pidgin won't pick it up.

I blindly saved the file before (because the file type was set to PEM and I flew
through this) and still had the stupid message after restarting Pidgin. Couldn't
figure out why until I went and looked at all the files in there, and low and 
behold....

Hope that helps!

Regards,

JK

Original comment by adida...@gmail.com on 11 Jun 2009 at 6:21

[GoogleCodeExporter]

Ok, now the windows installer code will install 
EquifaxSecureGlobaleBusinessCA.pem to
<Pidgin installation dir>\ca-certs

Original comment by somsaks on 14 Jun 2009 at 7:31

• Changed state: Fixed

[GoogleCodeExporter]

FWIW, I just upgraded from Fedora 10 to Fedora 11 and can confirm this bug is 
still
present with the Pigin/libpurple 2.5.6-1 packages included in the new distro. 
Redhat
has closed their equivalent bug with this message:

"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

Original comment by steevit...@gmail.com on 18 Jun 2009 at 6:33

[GoogleCodeExporter]

Totally agree!

BTW, I didn't add the certs for Linux, so the problem would still persist on 
those
platforms. 

Original comment by somsaks on 19 Jun 2009 at 4:15