Gmail.com: Validation failed

I have a dedicated server, firewall off, openfire installed. Everything set up like a breeze, but every time I log in/request authorization from a GTalk user, it fails and I get this in my debug log:


2007.08.02 13:50:36 OS - Trying to connect to gmail.com:5269(DNS lookup: xmpp-server3.l.google.com:5269)

2007.08.02 13:50:36 OS - Plain connection to gmail.com:5269 successful

2007.08.02 13:50:36 OS - Going to try connecting using server dialback with: gmail.com

2007.08.02 13:50:36 OS - Trying to connect to gmail.com:5269(DNS lookup: xmpp-server2.l.google.com:5269)

2007.08.02 13:50:37 OS - Connection to gmail.com:5269 successful

2007.08.02 13:50:37 OS - Sent dialback key to host: gmail.com id: 536768690A7D239F from domain: frosteddesign.com

2007.08.02 13:50:37 OS - Validation FAILED from: gmail.com id: 536768690A7D239F for domain: frosteddesign.com

2007.08.02 13:50:37 Error sending packet to remote server:

java.lang.Exception: Failed to create connection to remote server

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:212)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:184)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

… … etc etc etc.


Is this an SSL key problem, or what’‘s going on? Curiously, this randomly worked one time, and all of my GTalk friends popped on and I as able to talk to one. I signed out and back in, and they came back. I tried again with the firewall up, (though having the appropriate ports open) and it failed. Took the firewall back down, and I haven’'t connected to gtalk users since.

Any advice?

Edit: More information:

I thought it was also worth note that I have one person on my list with an account at macjabber.de, and I can connect to and validate with that server just fine. Here’'s the log:


2007.08.02 14:14:42 RS - Received dialback key from host: macjabber.de to: frosteddesign.com

2007.08.02 14:14:42 RS - Trying to connect to Authoritative Server: macjabber.de:5269(DNS lookup: macjabber.de:5269)

2007.08.02 14:14:42 RS - Connection to AS: macjabber.de:5269 successful

2007.08.02 14:14:42 RS - Asking AS to verify dialback key for id9460fa5f

2007.08.02 14:14:42 RS - Key was VERIFIED by the Authoritative Server for: macjabber.de

2007.08.02 14:14:42 RS - Closing connection to Authoritative Server: macjabber.de

2007.08.02 14:14:42 RS - Sending key verification result to OS: macjabber.de

2007.08.02 14:14:42 AS - Verifying key for host: macjabber.de id: 235957069

2007.08.02 14:14:42 AS - Key was: VALID for host: macjabber.de id: 235957069

2007.08.02 14:14:42 OS - Validation GRANTED from: macjabber.de id: 235957069 for domain: frosteddesign.com


I may be wrong as it has been a while but if you are trying to use the Server-to-Server part of Openfire to connect to GMail, you need DNS records set up exposing the service (SRV records to be exact) so it knows where your Openfire server is and then can connect to it (you may want to search this forum for that info). That may be why the macjapper.de domain works, it has that info published for GTalk to find.

I’'d recommend using the new version of the IM-Gateway instead (1.1.0 beta 6) as you can then create a link between your local Openfire account and a already set up GTalk account (much easier to me).

This is now beyond nuts.

The following two rules are currently in my DNS configuration ( named in Fedora Core 6):

xmpp-server.tcp IN SRV 0 0 5269 frosteddesign.com.

xmpp-server._tcp IN SRV 0 0 5269 frosteddesign.com.

I put them both there because no website seemed to agree on whether the _ had to be there at all or not. Figured it couldn’'t hurt to have both.

This is how I know it took effect:

# nslookup

> set type=SRV

> xmpp-server._tcp.frosteddesign.com

Server: 127.0.0.1

Address: 127.0.0.1#53

xmpp-server._tcp.frosteddesign.com service = 0 0 5269 frosteddesign.com.

But yet…


2007.08.02 16:51:49 OS - Trying to connect to gmail.com:5269(DNS lookup: xmpp-server.l.google.com:5269)

2007.08.02 16:51:49 OS - Plain connection to gmail.com:5269 successful

2007.08.02 16:51:49 OS - Going to try connecting using server dialback with: gmail.com

2007.08.02 16:51:49 OS - Trying to connect to gmail.com:5269(DNS lookup: xmpp-server4.l.google.com:5269)

2007.08.02 16:51:49 OS - Connection to gmail.com:5269 successful

2007.08.02 16:51:50 OS - Sent dialback key to host: gmail.com id: 16CC1A1E77EBC9B5 from domain: frosteddesign.com

2007.08.02 16:51:50 RS - Asking AS to verify dialback key for id454f4835

2007.08.02 16:51:50 OS - Validation FAILED from: gmail.com id: 16CC1A1E77EBC9B5 for domain: frosteddesign.com

2007.08.02 16:51:50 Error sending packet to remote server:

java.lang.Exception: Failed to create connection to remote server

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:212)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:184)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)


Same error. macjabber.de is still validating (although I went through a short phase during playing with my DNS records where it wouldn’'t), google is still hating me.

I prefer this to a transport, though – the protocol between the two is exactly the same, so it’‘d be a lot cleaner to connect verbatim than to implement a middle-man, so to speak. My last server (on dreamhost) could do this flawlessly, so there’'s gotta be a way to set up my own.

Any more ideas?

hmmm, I wonder if the cert is the issue. Maybe Google is stricter about the certificate authority. Are you using self-signed certs or do you have the from a CA?

Self-signed. The dedicated server kinda maxes out the budget on its own

It’'s worth noting, though, that regardless of whether I have SSL on or off in the server, I get the exact same response in my debug log.

Certs don’'t seem to matter with Googletalk and Openfire. I can connect fine with self signed certs or XMPP fed certs installed as long as I dont set encryption to “mandatory” in the Openfire security settings. If I do that, nothing works, but thats a whole different story

As for the OP’'s issue, I cannot see you having any SRV records set up.

Check this out:

http://demon.dopeman.org/xmpp_srv_test/?domain=frosteddesign.com

There’'s a section in RFC3920 that discusses what records you should publish. Set them up as per the RFC and check that they have been propagated and your problem will go away.

Wow, thanks a million, centrex! That’‘s a really great resource. I’'ll have to play with this today. That saves me a ton of headache

Score! Connected to gTalk users!!

For those Linuxers in need, this is the exact line I have in my zone file for frosteddesign.com, the domain I’'m running the server on:

xmpp-server.tcp.frosteddesign.com. IN SRV 5 0 5269 frosteddesign.com.

The problem was the priority. For some strange reason, on my system, giving that record a 0 priority blocked it from propagating to the public. Switching it to 5 and restarting named let it show up in the resource centrex posted.

Now all I need to do is figure out why everyone on my list sees me as offline… but that’'s a different forum search

Thanks everyone! I really appreciate it

This is no longer fun.

I’‘m continuing to have problems connecting. I got into google that one time, then it quit. So I loaded up Centrex’'s resource and kept spam-refreshing the page. About 1 time out of every 10, my SRV record would come up with some arbitrary number in the TTL. then on the next refresh, it goes away.

This is driving me insane!

Seemed to have been a propagation issue. A few hours later and everything’'s running smooth!

TomFrost ,

You are still lacking SRV records for the client. This will not cause problems with your original issue, but can cause problems with some clients. To be RFC compliant (look around page 87) you should look at doing the _im and _xmpp-client records (somewhere around page 64) as well. Just to avoid weird issues in future.