Up to Discussions in Openfire Support

This Question is Answered

27 Replies Last post: Jun 18, 2008 5:35 AM by Mark Straver  
Mark Straver Bronze
Mark Straver
47 posts since
May 11, 2008
Currently Being Moderated

May 27, 2008 2:26 PM

XMPP certificates + Openfire 3.5.1 = no go?

OK Folks, I've been trying just about everything I can to see what might be the problem with server to server connections, using an XMPP supplied server certificate, and even with:

 

  • xmpp.server.certificate.accept-selfsigned = true

  • xmpp.server.certificate.verify = false

  • xmpp.server.certificate.verify.chain = false

  • xmpp.server.certificate.verify.root = false

  • xmpp.server.certificate.verify.validity = false

 

I keep getting errors (undeliverable packets when requiring secure connections) and cannot get server 2 server connected using secure connections (they use a fallback dialback over plain text) -- client2server from my clients is fine, encryption works both using TLS and the old SSL method (even without the parameters above).

 

Even with these parameters set, the certmanager keeps complaining about the certificate (which has a double CN of which the first is a second level domain I use) and tells me the following:

 

2008.05.19 11:57:10 CertificateManager: SubjectAltName of invalid type found: EMAILADDRESS=XXXXX@wolfbeast.com, CN=wolfbeast.com, CN=jabber.wolfbeast.com, OU=Domain validated only, O=XXXXX, L=SkxC3xB6vde, C=SE

 

 

 

Update: From what I understood from other messages this debug message means that the xmpp extensions in the certificate are considered invalid and it would try the subject instead as a fallback (which would have thew same problem as that also has a first CN being the 2nd level domain and the second one being the actual correct hostname)...

 

 

Does this just mean that Openfire 3.5.1 simply cannot handle the certificate that was given out by XMPP.net? Is there a way around this error?

Should I go back to an earlier version of Openfire/Wildfire, one that is confirmed to work (and which one would that be)?

 

 

Thanks.

 

Mark.

 

Message was edited by: wolfbeest

Tags: openfire, server2server, security, certificate, connection
Jason Bronze
Jason
10 posts since
Jun 5, 2008
Currently Being Moderated
Jun 5, 2008 1:37 PM in response to: Mark Straver
Re: XMPP certificates + Openfire 3.5.1 = no go?

I'm having the same problem with s2s tls not working. The best I can see is in tests with the jabber.org server, it attempts to setup tls, exchanges certificates, but then just closes the connection and reverts to dialback. Because the cert works for c2s connections, I'm pretty sure that the cert itself is good, but OF is not doing something right with it.

 

IMO, the error from CertificateManager is bogus. After having looked at the code, what triggers that error message are non-otherName types in the SubjectAlternativeName field. I have a DNS type name on my certificate as well as the XMPP otherName and that DNS type causes that error message to pop up for me. Here is an openssl dump of the SubjectAlternativeName field on my cert...

 

X509v3 Subject Alternative Name:

othername:]]>, DNS:domain.org

 

Even though that error pops up, it does process the otherName that is on my certificate.

 

I'm still digging into this problem and will post more as I find answers.

Report Abuse
Mark Straver Bronze
Mark Straver
47 posts since
May 11, 2008
Currently Being Moderated
Jun 5, 2008 5:33 PM in response to: Jason
Re: XMPP certificates + Openfire 3.5.1 = no go?

 

Without the ability to actually read much of the java code (since that's not my cup of tea), but with some discussions aside here with people, it indeed seems to be an Openfire problem that it rejects the certificate because it doesn't check "any" supplied name for a match on the hostname in the cert, but only one. If that is the case in DNS names, SubjectAltName and Subject, it would probably refuse to use the cert as a whole, somewhere -- and revert to dialback over plaintext (I've seen that behaviour as well, see my other post about it).

 

 

c2s is fine, here, too. just not s2s.. and it stubbornly refuses, too.

 

 

The certificate checks out fine as well, in the browser, cert viewer and cleint side (who all seems to check a match on any of the fields, not just the one OF seems to check). Encryption for clients and the https webadmin is no problem. The certificate as-is checks out, even though having domain.tld on a cert for sub.domain.tld is illogical (but that is a different matter, and is actually being discussed as well in the XMPP standards circles at the moment).

 

 

There's definitely something strange going on in Openfire with this, that needs to be looked at by the devs. It may be the enforced SASL between servers that I saw attempted and fail before the TLS connection was dropped in favour of dialback (and in a public network that sounds like a strange thing to require too, I don't think any jabber server will have a server account for all other jabber servers out there set up ), or it may be certificate handling with multiple domain/host entries in it, I really don't know.

 

 

Report Abuse
Gaston Dombiak Jiver
Gaston Dombiak
3,751 posts since
Sep 26, 2001
Currently Being Moderated
Jun 6, 2008 1:07 AM in response to: Mark Straver
Re: XMPP certificates + Openfire 3.5.1 = no go?

Hey Mark,

 

I was not aware that a subjectDN could have several CN values. I filed this issue as JM-1384 and checked in a fix for this. It will be included for Openfire 3.5.2 to be released next week.

 

Thanks,

 

  -- Gato

Report Abuse
Mark Straver Bronze
Mark Straver
47 posts since
May 11, 2008
Currently Being Moderated
Jun 6, 2008 3:24 AM in response to: Gaston Dombiak
Re: XMPP certificates + Openfire 3.5.1 = no go?

 

Hi Gato,

 

 

It doesn't only seem to be a problem in the SubjectDN (fallback) but also in the XMPP extensions (which seems to be why the CertManager complains about the cert to begin with), where more than one CN is used (in the XMPP supplied certificates as well), apparently.

 

 

I guess it should be a global change to check for all CN values (and perhaps also DNS names) present in a certificate and when there is at least one match, consider it valid for the requested domain. What do you think?

 

 

Mark.

 

 

Report Abuse
Gaston Dombiak Jiver
Gaston Dombiak
3,751 posts since
Sep 26, 2001
Currently Being Moderated
Jun 6, 2008 1:59 PM in response to: Mark Straver
Re: XMPP certificates + Openfire 3.5.1 = no go?

Hey Mark,

 

The "CertificateManager: SubjectAltName of invalid type found: debug message is not printing the SubjectAltName but the subject DN. In fact that debug message should print the SubjectAlternativeName (that is not good for XMPP) or we should just get rid of that debug message. Anyway, AFAIK there is only one domain per SubjectAlternativeName and a certificate may have several SubjectAlternativeNames. That is why I suspect that if your certificate was not working in Openfire then it didn't have an XMPP SubjectAlternativeName and its subjectDN had more than one CN. And we fixed the latter so it should work now.

 

Regards,

 

  -- Gato

Report Abuse
Jason Bronze
Jason
10 posts since
Jun 5, 2008
Currently Being Moderated
Jun 6, 2008 2:17 PM in response to: Gaston Dombiak
Re: XMPP certificates + Openfire 3.5.1 = no go?

Over in the dev forum, I submitted a patch last night to get rid of that debug message.

Report Abuse
Mark Straver Bronze
Mark Straver
47 posts since
May 11, 2008
Currently Being Moderated
Jun 6, 2008 2:28 PM in response to: Gaston Dombiak
Re: XMPP certificates + Openfire 3.5.1 = no go?

 

Ah, that definitely explains a bit better!

 

 

I would suggest the debug message to be formatted a bit better or more informative as to what exactly is considered wrong. Just leaving it out wouldn't really be a good idea; if there is a certificate problem and you have debug on (for a reason obviously), getting no entries at all there is not going to be very informative and would have admins lost as to where to look for the possible cause.

 

 

I'm surprised that there would be no XMPP SubjectAlternativeName since it was the one I got through XMPP.net which specifically uses a routine to make sure the cert is xmpp compliant, i.e. having the right XMPP SubjectAlternativeName...  unless that was rejected as well.

 

 

I suspect it might have been rejected because of the same reason the SubjectDN caused problems, since the cert only seems to have one SubjectAlternativeName, it showing 2 DNS names of which the first once again is not the host name but the domain name:

 

Other Name:
1.3.6.1.5.5.7.8.5=0c 0d 77 6f 6c 66 62 65 61 73 74 2e 63 6f 6d
DNS Name=wolfbeast.com
DNS Name=jabber.wolfbeast.com

 

Would that be accepted as valid or not?

 

 

Report Abuse
Jason Bronze
Jason
10 posts since
Jun 5, 2008
Currently Being Moderated
Jun 6, 2008 2:38 PM in response to: Mark Straver
Re: XMPP certificates + Openfire 3.5.1 = no go?

Your two DNS Names are what triggers the invalid type messages and can be safely ignored. XMPP doesn't care about the DNS types, but instead of silently ignoring them, it throws the invalid type debug messages which IMO is wrong. The first otherName there is the XMPP otherName and it should be seen even though you get the complaints about the invalid type complaints about the DNS names.

Report Abuse
Mark Straver Bronze
Mark Straver
47 posts since
May 11, 2008
Currently Being Moderated
Jun 6, 2008 3:13 PM in response to: Jason
Re: XMPP certificates + Openfire 3.5.1 = no go?

Obviously, if that is what causes the error, Openfire rejects the whole entry (SubjectAlternativeName that all these entries are a part of) and tries to use the SubjectDN as fallback (the problems with which should be fixed with the new update coming up)..

 

So saying you can safely ignore the error here seems a little premature to me, since otherwise, if the xmpp extension would be accepted, it shouldn't even try to use the SubjectDN.

Report Abuse
Gaston Dombiak Jiver
Gaston Dombiak
3,751 posts since
Sep 26, 2001
Currently Being Moderated
Jun 6, 2008 3:16 PM in response to: Mark Straver
Re: XMPP certificates + Openfire 3.5.1 = no go?

Hey Mark,

 

If your certificate is using 1.3.6.1.5.5.7.8.5 then I don't know why the extension is not accepted. If you want you can send me your certificate so I can debug it here.

 

Thanks,

 

  -- Gato

Report Abuse
Mark Straver Bronze
Mark Straver
47 posts since
May 11, 2008
Currently Being Moderated
Jun 6, 2008 4:09 PM in response to: Gaston Dombiak
Re: XMPP certificates + Openfire 3.5.1 = no go?

shoots off an e-mail Hope that helps!

Report Abuse
Jason Bronze
Jason
10 posts since
Jun 5, 2008
Currently Being Moderated
Jun 6, 2008 5:46 PM in response to: Gaston Dombiak
Re: XMPP certificates + Openfire 3.5.1 = no go?

I was looking at the raw bytes in his otherName type and it looks different from mine. I have two layers of TaggedObject wrapping my UTF8String. His looks like it might be just a UTF8String with no TaggedObject wrappers. If that is the case, then it wouldn't decode properly and that could be causing his problems.

 

EDIT: Here are the raw bytes from my xmpp otherName attribute...

 

otherName:1.3.6.1.5.5.7.8.5 = a0 0f a0 0d 0c 0b 77 6f 6c 66 6e 65 74 2e 6f 72 67

 

I have the two a0 layers around the 0c layer, which the other cert does not have. Because the tagged layer decoding are hard coded in the current code, it can't handle this situation. Part of my otherName patch that I submitted last night would handle this correctly.

 

EDIT: For reference, I used openssl to generate my cert, with the openssl config at XMPP_Server_Certificates

Report Abuse
Mark Straver Bronze
Mark Straver
47 posts since
May 11, 2008
Currently Being Moderated
Jun 7, 2008 5:42 PM in response to: Jason
Re: XMPP certificates + Openfire 3.5.1 = no go?

 

Hey jkf,

 

 

Reading your post, I just realised, that the UTF-8 string for othername in my cert decodes to 2 control chars and then "wolfbeast.com" - so does that mean the xmpp extension there also doesn't use the actual hostname it was requested for (jabber.wolfbeast.com, the server name that is also used in Openfire) and would that cause an additional problem, or not?

 

 

Mark.

 

 

Report Abuse
Jason Bronze
Jason
10 posts since
Jun 5, 2008
Currently Being Moderated
Jun 7, 2008 9:33 PM in response to: Mark Straver
Re: XMPP certificates + Openfire 3.5.1 = no go?

The 0c and 0d are not interpreted as part of the string. That data is a Type-Length-Value attribute. The 0c is the type, in this case UTF8String, the 0d is the length, 13 bytes, and then you have your 13 character domain name.

 

If you look at my othername, I have a a0 0f a0 0d before the 0c type. Those are wrapper layers around the UTF8String. I have no idea what they technically do, but they're there and need unwrapping to get to the real type.

Report Abuse
Mark Straver Bronze
Mark Straver
47 posts since
May 11, 2008
Currently Being Moderated
Jun 8, 2008 3:15 AM in response to: Jason
Re: XMPP certificates + Openfire 3.5.1 = no go?

 

I understood that, the only thing I was wondering about was the fact that the UTF-8 name there isn't the same as the actual jabber server host name.  What seems to counter that is the fact that it does read the cert and uses it successfuly for https webadmin and c2s encryption, but not for s2s. So, for some reason s2s is handled differently. As requested by Gato in PM, I'll work on getting a second server set up, enable both debug logs, and post the results in this thread. It may take a little, I don't have the time and resources ready to do that quickly.

 

 

Report Abuse
Mark Straver Bronze
Mark Straver
47 posts since
May 11, 2008
Currently Being Moderated
Jun 8, 2008 4:27 AM in response to: Mark Straver
Re: XMPP certificates + Openfire 3.5.1 = no go?

After some more discussions, I've set up a test server locally (with a new, fresh install of Openfire) and initiated a s2s connection by sending a message from the test server (jabtest) to an account on my production server (jabber.wolfbeast.com).

 

The debug logs are included here.

 

Test setup:

jabber.wolfbeast.com:

  • Openfire 3.5.1

  • Self-signed certs accepted (xmpp.server.certificate.accept-selfsigned=true)

  • XMPP CA-signed certificate

 

jabtest:

  • Openfire 3.5.1

  • Standard install with all defaults

  • Self-signed certificate

 

jabber.wolfbeast.com debug log:

--- Marker inserted by admin at Jun 8, 2008 8:37:52 AM ---

2008.06.08 08:39:13 Connect Socket addr=/192.168.73.88,port=1190,localport=5269

2008.06.08 08:39:13 Connect Socket addr=/192.168.73.88,port=1191,localport=5269

2008.06.08 08:39:13 ServerDialback: RS - Received dialback key from host: jabtest to: jabber.wolfbeast.com

2008.06.08 08:39:13 ServerDialback: RS - Trying to connect to Authoritative Server: jabtest:5269(DNS lookup: jabtest:5269)

2008.06.08 08:39:13 ServerDialback: RS - Connection to AS: jabtest:5269 successful

2008.06.08 08:39:13 ServerDialback: RS - Asking AS to verify dialback key for id3272d1e5

2008.06.08 08:39:13 ServerDialback: RS - Key was VERIFIED by the Authoritative Server for: jabtest

2008.06.08 08:39:13 ServerDialback: RS - Closing connection to Authoritative Server: jabtest

2008.06.08 08:39:13 ServerDialback: RS - Sending key verification result to OS: jabtest

2008.06.08 08:39:13 Connection closed before session established

Socket addr=/192.168.73.88,port=1190,localport=5269

2008.06.08 08:39:22 LocalOutgoingServerSession: OS - Trying to connect to jabtest:5269(DNS lookup: jabtest:5269)

2008.06.08 08:39:22 LocalOutgoingServerSession: OS - Plain connection to jabtest:5269 successful

2008.06.08 08:39:23 LocalOutgoingServerSession: OS - Indicating we want TLS to jabtest

2008.06.08 08:39:23 LocalOutgoingServerSession: OS - Negotiating TLS with jabtest

2008.06.08 08:39:24 LocalOutgoingServerSession: OS - TLS negotiation with jabtest was successful

2008.06.08 08:39:24 LocalOutgoingServerSession: OS - Stream compression not supoprted by jabtest

2008.06.08 08:39:24 LocalOutgoingServerSession: OS - Starting EXTERNAL SASL with jabtest

2008.06.08 08:39:24 LocalOutgoingServerSession: OS - Error, EXTERNAL SASL authentication with jabtest failed

2008.06.08 08:39:24 LocalOutgoingServerSession: OS - Going to try connecting using server dialback with: jabtest

2008.06.08 08:39:24 ServerDialback: OS - Trying to connect to jabtest:5269(DNS lookup: jabtest:5269)

2008.06.08 08:39:24 ServerDialback: OS - Connection to jabtest:5269 successful

2008.06.08 08:39:24 ServerDialback: OS - Sent dialback key to host: jabtest id: 660fbefa from domain: jabber.wolfbeast.com

2008.06.08 08:39:24 Connect Socket addr=/192.168.73.88,port=1192,localport=5269

2008.06.08 08:39:24 ServerDialback: AS - Verifying key for host: jabtest id: 660fbefa

2008.06.08 08:39:24 ServerDialback: AS - Key was: VALID for host: jabtest id: 660fbefa

2008.06.08 08:39:24 ServerDialback: AS - Connection closed for host: jabtest id: 660fbefa

2008.06.08 08:39:24 Connection closed before session established

Socket addr=/192.168.73.88,port=1192,localport=5269

2008.06.08 08:39:24 ServerDialback: OS - Validation GRANTED from: jabtest id: 660fbefa for domain: jabber.wolfbeast.com

--- Marker inserted by admin at Jun 8, 2008 8:39:50 AM ---

 

jabtest debug log:

2008.06.08 10:39:13 LocalOutgoingServerSession: OS - Trying to connect to jabber.wolfbeast.com:5269(DNS lookup: jabber.wolfbeast.com:5269)

2008.06.08 10:39:13 LocalOutgoingServerSession: OS - Plain connection to jabber.wolfbeast.com:5269 successful

2008.06.08 10:39:13 LocalOutgoingServerSession: OS - Indicating we want TLS to jabber.wolfbeast.com

2008.06.08 10:39:13 LocalOutgoingServerSession: OS - Negotiating TLS with jabber.wolfbeast.com

2008.06.08 10:39:13 CertificateManager: SubjectAltName of invalid type found: EMAILADDRESS=xxxxxx@wolfbeast.com, CN=wolfbeast.com, CN=jabber.wolfbeast.com, OU=Domain validated only, O=Mark Straver, L=SkxC3xB6vde, C=SE

2008.06.08 10:39:13 CertificateManager: SubjectAltName of invalid type found: EMAILADDRESS=xxxxxx@wolfbeast.com, CN=wolfbeast.com, CN=jabber.wolfbeast.com, OU=Domain validated only, O=Mark Straver, L=SkxC3xB6vde, C=SE

2008.06.08 10:39:13 LocalOutgoingServerSession: Handshake error while creating secured outgoing session to remote server: jabber.wolfbeast.com(DNS lookup: jabber.wolfbeast.com:5269) javax.net.ssl.SSLHandshakeException: General SSLEngine problem

at com.sun.net.ssl.internal.ssl.Handshaker.checkThrown(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(Unknown Source)

at javax.net.ssl.SSLEngine.wrap(Unknown Source)

at org.jivesoftware.openfire.net.TLSStreamHandler.doHandshake(TLSStreamHandler.jav a:264)

at org.jivesoftware.openfire.net.TLSStreamHandler.start(TLSStreamHandler.java:158)

at org.jivesoftware.openfire.net.SocketConnection.startTLS(SocketConnection.java:1 66)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.secureAndAuthentic ate(LocalOutgoingServerSession.java:370)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:303)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:144)

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

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

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)

Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem

at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)

at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)

at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)

at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source)

at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)

at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)

at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Unknown Source)

at org.jivesoftware.openfire.net.TLSStreamHandler.doTasks(TLSStreamHandler.java:31 5)

at org.jivesoftware.openfire.net.TLSStreamHandler.doHandshake(TLSStreamHandler.jav a:225)

... 10 more

Caused by: java.security.cert.CertificateException: target verification failed of  wolfbeast.com

at org.jivesoftware.openfire.net.ServerTrustManager.checkServerTrusted(ServerTrust Manager.java:151)

... 18 more

2008.06.08 10:39:13 LocalOutgoingServerSession: OS - Going to try connecting using server dialback with: jabber.wolfbeast.com

2008.06.08 10:39:13 ServerDialback: OS - Trying to connect to jabber.wolfbeast.com:5269(DNS lookup: jabber.wolfbeast.com:5269)

2008.06.08 10:39:13 ServerDialback: OS - Connection to jabber.wolfbeast.com:5269 successful

2008.06.08 10:39:13 ServerDialback: OS - Sent dialback key to host: jabber.wolfbeast.com id: 3272d1e5 from domain: jabtest

2008.06.08 10:39:13 Connect Socket addr=/192.168.73.254,port=4091,localport=5269

2008.06.08 10:39:13 ServerDialback: AS - Verifying key for host: jabber.wolfbeast.com id: 3272d1e5

2008.06.08 10:39:13 ServerDialback: AS - Key was: VALID for host: jabber.wolfbeast.com id: 3272d1e5

2008.06.08 10:39:13 ServerDialback: AS - Connection closed for host: jabber.wolfbeast.com id: 3272d1e5

2008.06.08 10:39:13 Connection closed before session established

Socket  addr=/192.168.73.254,port=4091,localport=5269

2008.06.08 10:39:13 ServerDialback: OS - Validation GRANTED from: jabber.wolfbeast.com id: 3272d1e5 for domain: jabtest

2008.06.08 10:39:23 Connect Socket addr=/192.168.73.254,port=4092,localport=5269

2008.06.08 10:39:24 CertificateManager: SubjectAltName of invalid type found: EMAILADDRESS=xxxxxx@wolfbeast.com, CN=wolfbeast.com, CN=jabber.wolfbeast.com, OU=Domain validated only, O=Mark Straver, L=SkxC3xB6vde, C=SE

2008.06.08 10:39:24 CertificateManager: SubjectAltName of invalid type found: EMAILADDRESS=xxxxxx@wolfbeast.com, CN=wolfbeast.com, CN=jabber.wolfbeast.com, OU=Domain validated only, O=Mark Straver, L=SkxC3xB6vde, C=SE

2008.06.08 10:39:24 CertificateManager: SubjectAltName of invalid type found: EMAILADDRESS=certmaster@jabber.org, CN=StartCom Class 1 Intermediate CA - Jabber Software Foundation, OU=Secure Certificate Signing, O=Jabber Software Foundation, ST=Colorado, C=US

2008.06.08 10:39:24 CertificateManager: SubjectAltName of invalid type found: EMAILADDRESS=admin@startcom.org, CN=Free SSL Certification Authority, OU=CA Authority Dep., O=StartCom Ltd., L=Eilat, ST=Israel, C=IL

2008.06.08 10:39:24 Logging off jabtest/6acdb535 on org.jivesoftware.openfire.net.SocketConnection@2fe032 socket: Socket addr=/192.168.73.254,port=4092,localport=5269  session: org.jivesoftware.openfire.session.LocalIncomingServerSession@8d539f status: 1 address: jabtest/6acdb535 id: 6acdb535

2008.06.08 10:39:24 Connect Socket addr=/192.168.73.254,port=4093,localport=5269

2008.06.08 10:39:24 ServerDialback: RS - Received dialback key from host: jabber.wolfbeast.com to: jabtest

2008.06.08 10:39:24 ServerDialback: RS - Trying to connect to Authoritative Server: jabber.wolfbeast.com:5269(DNS lookup: jabber.wolfbeast.com:5269)

2008.06.08 10:39:24 ServerDialback: RS - Connection to AS: jabber.wolfbeast.com:5269 successful

2008.06.08 10:39:24 ServerDialback: RS - Asking AS to verify dialback key for id660fbefa

2008.06.08 10:39:24 ServerDialback: RS - Key was VERIFIED by the Authoritative Server for: jabber.wolfbeast.com

2008.06.08 10:39:24 ServerDialback: RS - Closing connection to Authoritative Server: jabber.wolfbeast.com

2008.06.08 10:39:24 ServerDialback: RS - Sending key verification result to OS: jabber.wolfbeast.com

--- Marker inserted by admin at Jun 8, 2008 10:39: