XMPP certificates + Openfire 3.5.1 = no go?

Mark_Straver1 · May 19, 2008, 12:09pm

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

Jason23 · June 5, 2008, 6:37pm

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.

Mark_Straver1 · June 5, 2008, 10:33pm

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.

Gaston_Dombiak · June 6, 2008, 6:07am

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

Mark_Straver1 · June 6, 2008, 8:24am

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.

Gaston_Dombiak · June 6, 2008, 6:59pm

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

Jason23 · June 6, 2008, 7:17pm

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

Mark_Straver1 · June 6, 2008, 7:28pm

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?

Jason23 · June 6, 2008, 7:38pm

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.

Mark_Straver1 · June 6, 2008, 8:03pm

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.

Gaston_Dombiak · June 6, 2008, 8:16pm

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

Mark_Straver1 · June 6, 2008, 9:09pm

shoots off an e-mail Hope that helps!

Jason23 · June 6, 2008, 10:13pm

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

Mark_Straver1 · June 7, 2008, 10:42pm

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.

Jason23 · June 8, 2008, 2:33am

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.

Mark_Straver1 · June 8, 2008, 8:15am

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.

Mark_Straver1 · June 8, 2008, 8:59am

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 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.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=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:43 AM —

Message was edited by: wolfbeest - killed autoformatting of logs by clearspace

Gaston_Dombiak · June 8, 2008, 3:58pm

Hey Mark,

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

Based on that I would say that TLS was fine but the s2s failed while doing SASL EXTERNAL. After that server dialback was used. SASL External is going to validate the identity found on the certificate with the XMPP of the server. I remember your certificate had an XMPP subjectAltName for wolfbeast.com so the XMPP of your server should be wolfbeast.com and not jabber.wolfbeast.com. So my question is which is the XMPP domain of your server?

Regards,

– Gato

Mark_Straver1 · June 8, 2008, 5:03pm

Based on that I would say that TLS was fine but the s2s failed while doing SASL

EXTERNAL. After that server dialback was used. SASL External is going to

validate the identity found on the certificate with the XMPP of the server. I

remember your certificate had an XMPP subjectAltName for wolfbeast.com so the

XMPP of your server should be wolfbeast.com and not jabber.wolfbeast.com.

So

my question is which is the XMPP domain of your server?

That was exactly my question to Peter StAndre (and Eddy at Startcom) as

well after seeing the UTF-8 decoded string being wolfbeast.com – No

reply yet on that as of the time of this post.

The jabber hostname (jabber domain) is jabber.wolfbeast.com, not

wolfbeast.com! (JIDs being username@jabber.wolfbeast.com) I requested

the certificate specifically for jabber.wolfbeast.com, too. So not only

is the CN wolfbeast.com used in the subject, DNS name, and a few other

places, but also the xmpp extension doesn’t match what the cert was

requested for. No wonder it doesn’t work as it should…

–

Gaston_Dombiak · June 8, 2008, 5:06pm

Hey Mark,

In that case we found the root problem. The certificate needs to be regenerated so that the XMPP extension (ie subjectAltName) matches your XMPP domain.

Regards,

– Gato