Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Pidgin started prompting me to accept/reject new gtalk SSL certificate a few days ago and I am not able at the moment to tunnel the traffic to check if it would continue to happen or if it wouldn't (which would mean an attempt of SSL MITM attack).

How (and where) can I check if the new SSL certificate is valid? Can I even do that? Is there a place with a list of certificates where I could compare them?

I found this question, but I am not sure if that is the answer I am looking for. Answers to that question say that it is clients job to validate the certificate, but what happens to me is that pidgin (in my case the client) tells me "The certificate for could not be validated. The certificate claims to be from "" instead. This could mean that you are not connecting to the service you believe you are.". Now, I may be overparanoid but I would still really like to know how and if I can manually check this. Thank you.

share|improve this question
up vote 13 down vote accepted

The message you quote means: "I wanted to talk to a server called, but what responded there seems to use a certificate which has the name in it, and not". This means that either of these is true:

  • some ill-intentioned third party is actively redirecting your connection to the wrong server, possibly by DNS poisoning;
  • some mishap at your ISP implied a bad DNS configuration which emulates the effect of DNS poisoning, redirecting your connection attempt to the wrong server;
  • Google does not know how to do SSL;
  • there is something fishy in your Pidgin configuration.

From here, connecting to port 443 on results in a server certificate which includes the name: subject=/C=US/ST=California/L=Mountain View/O=Google Inc./, which is correct.

Note that Google is known to play tricks with the DNS. From my home machine, is resolved to an alias to, which has IP From another machine on another continent, is resolved to an alias to, which this time has IP There is obviously some sort of worldwide load-balancing in action here.

Bottom-line: you cannot check "by yourself" whether a certificate is good or not, save perhaps by phoning the Google headquarters and having them spell out the certificate fingerprint (which they might agree to; they are rumoured to value such kind of humour). Actually, the message you get is a rather definite indication that you do not get the right certificate, so you'd better use the message as a symptom and investigate if you indeed connect to the right server. I suggest trying Wireshark to see what server Pidgin is actually contacting, and what happens at the SSL level.

share|improve this answer
So, what you're saying is that Pidgin is effectively bugging users unnecessarily, since nothing really can be done with the information it displays? – Tomislav Nakic-Alfirevic Jun 12 '12 at 21:57
it's the client, has some standard xmpp SRV DNS records pointing to, sometimes a client tries to match the ssl cert against the wrong domain (I've seen Gajim and Psi do this on google's cert before). And then there are some load balancing CNAMES added for a fun mix meaning more domains it can be matched against. Unfortunately this is an issue cause one can nolonger check cert validity. – ewanm89 Jun 24 '12 at 10:14
That "worldwide load-balancing" you're talking about is Anycast – Shadok Oct 23 '12 at 16:42

How (and where) can I check if the new SSL certificate is valid?

  1. Save the certificate as a file (DER, Base-64, or PKCS #7).
  2. Read the Issuer for the certificate.
  3. Obtain the issuer's certificate.
    • The location of the issuer's certificate is typically specified by the "Authority Information Access" field.
  4. If the issuer's certificate is not a root CA then continue up the chain until you obtain all the certificate from the root CA to the certificate of interest.
  5. Starting at the certificate signed by the root CA check each certificate for validity period and correct subject naming
  6. Read the Signature Algorithm field for the has and encryption type used.
  7. Using the public key from the signing certificate decrypt the signature
  8. Calculate the hash value using the algorithm specified in the Signature Algorithm field of the certificate data up to but not including the signature.
  9. Compare the decrypted value to the calculated hash. If they match the signature is valid.
  10. Continue down the chain until you encounter a certificate which is invalid.
share|improve this answer
I guess the problem with pidgin is that I don't have any of these fields.. Only BEGIN CERTIFICATE and END CERTIFICATE and what is in between of course. And I have the calculated hash value (SHA1). – pootzko Nov 4 '11 at 20:05
@pootzko What does it display between BEGIN and END? Does it look like this: a1 02 b3 04 c5 5d 66 7e ? – this.josh Nov 4 '11 at 21:52
nope, it's compact. alphanumeric + a few special characters here and there... this is a short sample, part of one of the lines: "GVybmV0IEF1dGhvcml0eTAeFw0xMTEwMjUxOTIxNTd". – pootzko Nov 5 '11 at 0:28
OpenSSL command line tools can convert the BEGIN/END CERTIFICATE blob into useful data... "OpenSSL x509 -inform PEM -text -in <text file>" – davenpcj Aug 29 '13 at 16:48

If you had Pidgin logging into two accounts, a Google Apps account and a Gmail account, then no worries, there's no certificate error. It's just a Pidgin bug that they've been ignoring for the past year.

share|improve this answer

I just thought I'd throw out the solution to this problem. If you open the account setting for your gmail account and click on the advanced tab you'll probably see "Connect server:" set to I'm not exactly sure what's going on (if this an old default or something), but getting rid of that solves the problem.

My guess from what I've seen in my Wireshark session is that it's connecting to, asking for the certificate and then getting confused by the result (I'm not sure if it's getting the gmail cert and being confused because it connected to or if google is spitting up a bad cert because you're connecting to one server and asking for the cert from another server).

share|improve this answer
I still get the SSL Certificate Verification dialog, even when setting Connect server: to As you suggest, I think it is confused because it connected to but got the gmail cert. – Mark Booth Mar 30 at 9:25

I resolved this by updating pidgin. 2.10.7 doesn't give me the certificate error that 2.7.11 did.

Though it was actually quite challenging to attempt to verify the certificate presented; I was never able to get any google service to give me a cert with the same thumbprint as the one pidgin was complaining about.

I don't think that's a MITM attack, just a lack of publication of the certs, and my own ability to figure out which server is ultimately answering the request.

But I wasn't comfortable accepting the error, so I hope the upgraded pidgin isn't doing that for me.

share|improve this answer

A different solution to the same issue: I simply had to delete a space character from the field:

Modify Account > Advanced > Connect server:

Not sure why the message only started showing now; I haven't changed the settings for ~ 2 years. Maybe this might help someone else.

share|improve this answer

Put the domain name ( into a Firefox or Chrome with HTTPS ( and check whether the URL bar/lock icon is green or not. Green means that the browser trusts the connection. After that check the certificate fingerprint in the browser and compare with the fingerprint from the Pidgin window.

I don't think that the domain name difference ( vs. is a big issue, both are Google's domains.

Nowadays redirects to, so I use instead which only shows a 404 page without redirection.

share|improve this answer
This doesn't address the OP's question. – Adi Jul 23 '14 at 17:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.