Feed for content matching tag 'ssl'

webmaster@jivesoftware.com — Thu, 01 Jan 1970 00:00:00 GMT

Disclaimer

I cannot guarantee that this tutorial is faultless as I spend a lot of time setting up openfire to work with red5 via Spark over rtmps using Linux as a client. I do not want to destroy my now working installation in order to test this tutorial but I have written this the day after getting everything working so it is fresh in my mind. If you have a problem getting it going then leave a message below and I will modify this document:

Known bugs

When you place a call to someone they must also place a call back to you! They will not be notified that a call is waiting for them;

The chat window will also open but it will open a new chat window each time you place a call, even if that call is to the same person. You will therefore wind up with several tabs to the same person if you make multiple calls to them without closing the chat window in between. You can simply close the additional windows manually;
The other person will not get a notification asking 'Do you want to accept this call' but their camera will not be turned on until they place a call back to you;
Each person who you want to be able to call must have the same modifications applied to the Spark client;
If you call a second person then I am ot sure what will happen if you have not closed the first call window. It may work, but to be on the safe side you will be better of closing the first call window before placing a second call;

Sorry, but I couldn't figure out the openfire API sufficiently to make the above work without introducing additional bugs which I thought were worse! If someone with a better knowledge of the openfire API wants to let me know how to fix these problems then I will happily fix them. I am sure it is just a couple of lines of code but I could not find an example.

Description

This document describes how to set up Openfire, the Red5 plugin and Spark for secure video messaging. It will not cover how to set up SparkWeb for secure audio/video but you may be able to work out how to do it after reading this. This document is more focused on getting things to work on both Windows and Linux (I am using Debian etch for the server and Debian Lenny for the client, tested on Windows XP and Vista for Spark client integration). If you do not need Linux support then you can skip several of the steps. I have made several changes to the red5-plugin.jar file in order to make opening a browser possible under Linux (It should also work on the mac). All the files you need should be attached except for XULRunner but that is described later on.

Requirements

Openfire (3.6.0a);
Spark (2.5.8);
Apache 2;
On Linux (and possible windows) you will need a valid SSL certificate (not self signed). This is because of the use of MozSwing and XULRunner. MozSwing will not prompt you if you are using a self signed certificate. You can pick one up for £15 at www.godaddy.com but I found there customer service to be somewhat lacking;
On Linux you will need to use the Flash Player version 10 which is a beta release. It is the only version that can handle web camera integration.
XULRunner will be required but you MUST use the version from the MozSwing project as it has been modified to work with MozSwing. Mozswing is used to open a web browser in order to play the Flash Movie.

Modified files

I found that I had to modify a few files in order to make things work. You may find your distance with the existing openfire.jar varies but I could not make it work without editing. The modifications I made were:

openfire.jar was modified:

org.jivesoftware.openfire.http.HttpBindManager – has been edited to hard code the SSL port as 8443. I found that I could not set the SSL port and it was always '0' with the build of openfire I used; You do not strictly need this modification if you do not mind the initial http request being unencrypted. The Flash movie will still send its data stream in an encrypted format;

red5.war was modified:

/video/320x240.lzx – This is the video file that is used to show the audio and video. It is compiled into a .swf file using OpenLaszlo. You must use version 3 (I used 3.2) of OpenLaszlo as it will not compile on more recent versions;

red5-plugin.jar was modified:

This can be found inside of the red5.war/spark folder but you must use the one attached to this document. I have modified Red5Plugin.java so that it will read the Red5.properties file (it was looking in the wrong place previously) and added a class SparkBrowser which replaces BareBonesBrowserLauncher.

The above compiled versions of the files are attached.

How the sep-up links together

A request from the Spark client using audio/video is sent to the apache server which will act as a proxy server. This request will go to apache which will then forward that request onto the Red5 server. This allows apache to handle the SSL encryption/decryption which I am not certain that the version of Red 5 in the red5-plugin can do (see http://gregoire.org/2008/05/26/rtmps-in-red5/). Hence I use apache to handle this functionality.

Request cycle

Spark (rtmps – ssl encrypted) => Apache 2 (decrypts) => Red 5 (unencrypted)

Response cycle

Red 5 (unencrypted) => Apache 2 (Encrypts) => Spark (decrypts)

The above is a basic description of the request/response cycle. In actuality Spark is using a web browser which plays the flash movie and handles SSL encryption/decryption. RTMPS (Real Time Media Protocol Secure) is the protocol used by flash to talk with Red 5. RTMPS is simply RTMPT (Real Time Media Protocol Tunneled) done over SSL, RTMPT is RTMP over HTTP.

So ... all communication is RTMP but in this case we will do it over HTTP and encrypt it using SSL. That is why we need Apache and why Spark uses a web browser. They are required to encode/decode the SSL streams.

Set up

Install openfire on your server:

sudo dpkg -i openfire_3.6.0a_deb_all.deb
Install the red5 plugin:

Download the Red 5 plugin which is currently in the beta plugins section. You can currently get it from here http://www.igniterealtime.org/projects/openfire/plugins-beta.jsp
Shutdown the openfire server:

sudo /etc/init.d/openfire stop
Copy the red5 plugin that you downloaded to the openfire plugins directory at /usr/share/openfire/plugins;
Startup openfire:

sudo /etc/init.d/openfire start

You will see the red5 war file expand into a folder called red5;
Shutdown openfire again;
There are some files attached to this document, download them and do the following:

Copy the openfire-https-8443.jar to /usr/share/openfire/lib/openfire-https-8443.jar and DELETE the existing openfire.jar. The new jar file forces HTTP_BIND ssl to work on port 8443. Without it I found that HTTP_BIND with ssl does not work.

This step is not strictly necessary but it will allow you to call the HTML page containing the flash movie over SSL. The movie will be encrypted whether or not you do this as it uses HTTPS to apache. How you call the HTML page containing the movie is irrelevant, it is how the movie in the HTML page connects to Red 5 that is critical. Therefore you may not need this step.
Copy the file video320x240.lzx.swf to /usr/share/openfire/plugins/red5/video. It contains a modification that allows us to pass a parameter 'url' containing the rtmps protocol necessary for SSL encryption. Without this modification the movie uses a hard coded string of 'rtmp:/oflaDemo' and will not be encrypted;
Restart openfire;
Setup your apache virtual host. You will need to use a valid SSL certificate (not self signed) so bear this in mind when you do this. If you are trying to set this up as a subdomain and your SSL certificate is not for the subdomain then it will fail. Luckily, integrating red5 into your existing main default host should cause 99% of people no problems. This is because we only need to proxy for URLS of the following form:

/open
/close
/idle
/send

I have attached a copy of a virtual host that you can use as a template;
Copy the folders /usr/share/openfire/plugins/red5/video and /usr/share/openfire/plugins/red5/screen to your apache document root red5 folder (you will need to create the red5 folder). This may be /var/www/YOUR_DOMAIN_NAME/red5;
Restart Apache;
Download the attached red5-plugin.jar file and place it in your client side Spark user plugins folder. On Linux this is located at /home/USER_NAME/.Spark/plugins. you could also place it in the main Spark folder which for me is at /usr/local/Spark/plugins, it will then be automatically copied for each user to their own folder. You MUST use the attached version as it has the 'Call' option added back into the right click menu. For some reason it seemed to vanish on the latest downloaded version from:

http://demo.free-solutions.ch/clearspace/docs/DOC-1066

which was dated the 8^th September when this document was written.
As this document will only allow attachments of 20Meg you will now need to manually install XULRunner as it can not be included in the red5-plugin.jar file due to its download size.

YOU MUST INSTALL XULRunner FROM THE MOZSWING PROJECT AS IT IS PATCHED TO WORK WITH MOZSWING!

Download it from here http://sourceforge.net/projects/mozswing
Copy the folder moszswing-x.x/native/YOUR_OS_VARIENT/xulrunner to /home/YOUR_USER_NAME/.Spark/plugins/red5-plugin/xulrunner
Modify the file /home/YOUR_USER_NAME/.Spark/plugins/red5-plugin/Red5.properties so that it points to your server.

Proving it is encrypted

Download Wireshark and use it to analyse the packets being send from the flash movie. To do this on Linux (it should be the same on Windows):

Press the 'List available capture devices' button which is the first button on the toolbar;
Stop all activity that may be talking from your computer to your server on port 443! This would generally mean that you should not have any web pages open to your Apache over HTTPS.
Press Start for your current interface (I am on wlan1 but you may be on eth0 or eth1). It should have numbers changing next to it which indicates that packets are traversing the interface;
Start your call from Spark by right clicking on a user and selecting call (you do not need another user to test this – just call someone on your list even if they are not online and do not have their client modified yet);
Wait a few seconds while Wireshark captures the data;
Press the 'Stop' button on Wireshark, it is the 4^th button on the toolbar;
In the Filter, type 'tcp.port==443'. You should see some packets listed, if you don't then your setup was not communicating via port 443 and was therefore NOT encrypted. If this is the case then delete the filter and look at the packets manually. If it is using port 1935 (the default rtmp unencrypted port or port 80 then you are not secured by SSL).

FINISHED

Start Spark and try to place a call to a user who has the same red5-plugin.jar and XULRunner setup as you.

Hopefully in the future this functionality will be built into the Red5-plugin and Spark to make this easier. It has already been added to the 'todo' list.

I found the above complicated to set up and what I have works for me. If you know of a better way to do it then I am all ears!

If you find that this document needs to be modified due to an error then let me know.

webmaster@jivesoftware.com — Thu, 01 Jan 1970 00:00:00 GMT

I originally tried following the Openfire documentation for importing certificates via the command line keytool; i'd attempted to do this the first time, after configuring the server and then shutting it down. I added the certificate via keytool and upon restarting the server, saw through the web interface and in the logs/error.log that the keystore was considered corrupt.

I shutdown the server and removed all of the files in resources/security (in an effort to force regeneration). I started the server, logged in via the web interface, went to the security certificates page; it was naturally complaining of a corrupt keystore (since none existed, i presume) and asked it to generate its own keys. It did, and presented them in the reloaded web view.

After of intermediary hunting, it is always replicable to perform the above paragraph, then shutdown the server, *do nothing*, and start the server. Starting the server now complains about the keystore being corrupt (even though it just created the keystore itself during its last life cycle, and it was untouched by other processes).

I added a stack traced dump to catch block in the openfire class SSLConfig from where the error was coming (, recompiled and deployed the jar). The stack trace is:

java.io.EOFException
        at java.io.DataInputStream.readInt(DataInputStream.java:358)
        at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:627)
        at java.security.KeyStore.load(KeyStore.java:1150)
        at org.jivesoftware.openfire.net.SSLConfig.<clinit>(SSLConfig.java:99)
        at org.jivesoftware.openfire.spi.ConnectionManagerImpl.isClientSSLListenerEnabled( ConnectionManagerImpl.java:584)
        at org.jivesoftware.openfire.spi.ConnectionManagerImpl.createClientSSLListeners(Co nnectionManagerImpl.java:379)
        at org.jivesoftware.openfire.spi.ConnectionManagerImpl.createListeners(ConnectionM anagerImpl.java:92)
        at org.jivesoftware.openfire.spi.ConnectionManagerImpl.start(ConnectionManagerImpl .java:826)
        at org.jivesoftware.openfire.XMPPServer.startModules(XMPPServer.java:600)
        at org.jivesoftware.openfire.XMPPServer.start(XMPPServer.java:466)
        at org.jivesoftware.openfire.XMPPServer.<init>(XMPPServer.java:161)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
        at java.lang.Class.newInstance0(Class.java:350)
        at java.lang.Class.newInstance(Class.java:303)
        at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:106)
        at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:51)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
        at com.install4j.runtime.Launcher.main(Unknown Source)

As far as configuration, my environment is:

Openfire 3.5.2
1.5.0_14 Sun Microsystems Inc. -- Java HotSpot(TM) Server VM
jetty-6.1.x
OS / Hardware: Linux / i386

and the system properties i have set were xmpp.socket.ssl.active to 'true' and xmpp.socket.ssl.keypass to the correct password.

Any ideas?

webmaster@jivesoftware.com — Thu, 01 Jan 1970 00:00:00 GMT

Hello people!

Could you explain how to configure the Apache to let the Jwchat to communicate with ssl http-bind port?

I'm not strong in Apache and haven't find any helpfull material on this topic.

I have the following configuration (all works fine):

Openfire 3.4.1

8080 port for non ssl binding

Apache 2.2.6

RewriteRule http-bind/ http://localhost:8080/http-bind/ [P]

Thank a lot!!!

webmaster@jivesoftware.com — Thu, 01 Jan 1970 00:00:00 GMT

Exception:

java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.String.charAt(Unknown Source) at org.bouncycastle.asn1.x509.X509Name.(Unknown Source) at org.bouncycastle.jce.X509Principal.(Unknown Source) at org.bouncycastle.jce.provider.X509CertificateObject.getIssuerDN(Unknown Source) at org.jivesoftware.util.CertificateManager.isSigningRequestPending(CertificateMan ager.java:341) at org.jivesoftware.openfire.admin.ssl_002dcertificates_jsp._jspService(ssl_002dce rtificates_jsp.java:542) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1093) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:11 8) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:42) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:99) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect ion.java:206) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.j ava:829) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) How do you fix this?

kajtzu@basen.net — Thu, 01 Jan 1970 00:00:00 GMT

Hi,

With openfire 3.4.2, clients can access the server just fine using SSL (they do not complain) but when accessing /ssl-certificates.jsp in the admin console the page prints out the following exception:

java.security.InvalidKeyException: Supplied key (null) is not a RSAPrivateKey instance

at org.bouncycastle.jce.provider.JDKDigestSignature.engineInitSign(Unknown Source)

at java.security.Signature.initSign(Signature.java:480)

at org.bouncycastle.jce.PKCS10CertificationRequest.(Unknown Source)

at org.jivesoftware.util.CertificateManager.createSigningRequest(CertificateManage r.java:331)

at org.jivesoftware.openfire.admin.ssl_002dcertificates_jsp._jspService(ssl_002dce rtificates_jsp.java:430)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1093)

at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:11 8)

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:65)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:41)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:69)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:98)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)

at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)

at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)

at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect ion.java:211)

at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:313)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)

at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.j ava:830)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)

at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

Any thoughts?

webmaster@jivesoftware.com — Thu, 01 Jan 1970 00:00:00 GMT

Hello,

I had 3.4.1 running more or less smoothly, and this morning I installed the update to 3.4.2. I have two Windows 2003 servers, a home office and a satellite office. The primary reason I set up the two servers is that I require encrypted communications between the two offices. I don't need or want outside servers to be able to talk to them. I set up the two servers on each other's whitelists and installed self-signed certificates on each server. Under 3.4.1, I fought with it for a while, and had to set the server property xmpp.server.certificate.verify to false, but after I did that it was working fine.

When I installed the 3.4.2 update, I couldn't communicate to people on the other server. My client (Trillian) returns a message "Unable to deliver message. Server reports (404)(none)". I have encryption set to required. If I turn off encryption, it works fine, so I'm pretty sure the problem is isolated to something with SSL. SSL seems to work fine with everything else. Clients connect with no problems (that is also set to required) and my admin interface works on SSL. (Although it generates an expected certificate warning.)

I tried deleting and re-generating certificates on both sides. I tried creating certificates using openSSL. I tried using the old-fashioned keytool method. I deleted the keystore and re-installed openfire. I can't think of anything else that could be causing it to fail. In the server logs, I get the following messages:

On the local side (initiator) I get this in the error.log:

2007.12.10 15:02:34 [org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSes sion(LocalOutgoingServerSession.java:338)
] Error creating secured outgoing session to remote server: jabber.remotedomain.com(DNS lookup: jabber.remotedomain.com:5269)
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at com.sun.net.ssl.internal.ssl.EngineInputRecord.bytesInCompletePacket(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(Unknown Source)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at org.jivesoftware.openfire.net.TLSStreamHandler.doHandshake(TLSStreamHandler.jav a:211)
at org.jivesoftware.openfire.net.TLSStreamHandler.start(TLSStreamHandler.java:157)
at org.jivesoftware.openfire.net.SocketConnection.startTLS(SocketConnection.java:1 65)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.secureAndAuthentic ate(LocalOutgoingServerSession.java:369)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:302)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:143)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:205)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:185)
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)

On the remote side, I get this in the warn.log:

2007.12.10 14:02:36 Stream error detected. Session: org.jivesoftware.openfire.session.LocalIncomingServerSession@e72f0c status: 1 address: jabber.remotedomain.com/930ffb7 id: 930ffb7
java.lang.RuntimeException: Delegated task threw Exception/Error
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.readNetRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(Unknown Source)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at org.jivesoftware.openfire.net.TLSStreamHandler.doHandshake(TLSStreamHandler.jav a:211)
at org.jivesoftware.openfire.net.TLSStreamHandler.start(TLSStreamHandler.java:157)
at org.jivesoftware.openfire.net.SocketConnection.startTLS(SocketConnection.java:1 65)
at org.jivesoftware.openfire.net.SocketReadingMode.negotiateTLS(SocketReadingMode. java:72)
at org.jivesoftware.openfire.net.BlockingReadingMode.readStream(BlockingReadingMod e.java:126)
at org.jivesoftware.openfire.net.BlockingReadingMode.run(BlockingReadingMode.java: 62)
at org.jivesoftware.openfire.net.SocketReader.run(SocketReader.java:119)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at com.sun.net.ssl.internal.ssl.HandshakeMessage$CertificateRequest.<init>(Unknown Source)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(Unknown Source)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.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 4)
at org.jivesoftware.openfire.net.TLSStreamHandler.doHandshake(TLSStreamHandler.jav a:224)
... 7 more
2007.12.10 14:02:37 Closing session due to incorrect hostname in stream header. Host: remotedomain.com. Connection: org.jivesoftware.openfire.net.SocketConnection@12eabae socket: Sockethttp://addr=/22.22.22.22,port=1547,localport=5269 session: null

Obviously, domains and IP addresses are obfuscated above. The real domains are correct, and can resolve correctly from either side of the connection. Also, the IP address in the last line of the remote warn.log is the correct IP address for the server.

On both firewalls, I have ports 5222, 7777 and 5269 forwarded to the server. Although I didn't have them before, I created SRV records on both DNS servers for TCP ports 5222 and 5269.

Thank you very much in advance, and any help would be greatly appreciated. These are production servers, and I can't think of anything else to try.

webmaster@jivesoftware.com — Thu, 01 Jan 1970 00:00:00 GMT

I've recently been working on getting a CA signed certificate installed in Openfire, requested through XMPP.net and it seems to "partially" work, but still keeps giving issues apparently.

What I mean with "partially" is the fact that the certificate is accepted as CA signed and installed properly in the keystore, the web admin interface successfully negotiates SSL, and presents a verified certificate in my browser. The client connection on 5223 also works without errors (nothing in the logs apart from regular authentication realm information in debug.log). What doesn't seem to work as it should is s2s connections, which uses a fallback (if I understood correctly) to server dialback in most cases, and the hostname in openfire is not accepted as valid (error is displayed for AltName). Some log excerpts below:

Outgoing server connection (debug log):

2008.05.12 06:12:38 LocalOutgoingServerSession: OS - Trying to connect to jabber.org:5269(DNS lookup: jabber.org:5269)

&n bsp; 2008.05.12 06:12:39 LocalOutgoingServerSession: OS - Plain connection to jabber.org:5269 successful &nb sp; 2008.05.12 06:12:39 LocalOutgoingServerSession: OS - Indicating we want TLS to jabber.org &nb sp; 2008.05.12 06:12:40 LocalOutgoingServerSession: OS - Negotiating TLS with jabber.org* &n bsp; 2008.05.12 06:12:40

&n bsp; CertificateManager: SubjectAltName of invalid type found:

&n bsp; EMAILADDRESS=hostmaster@jabber.org, CN=jabber.org, CN=*.jabber.org,

&n bsp; OU=Domain validated only, O=XMPP Standards Foundation, L=Denver,

&n bsp; ST=Colorado, C=US*

* & nbsp; 2008.05.12 06:12:40

&n bsp; CertificateManager: SubjectAltName of invalid type found:

&n bsp; EMAILADDRESS=hostmaster@jabber.org, CN=jabber.org, CN=*.jabber.org,

&n bsp; OU=Domain validated only, O=XMPP Standards Foundation, L=Denver,

&n bsp; ST=Colorado, C=US*

&n bsp; 2008.05.12 06:12:43 LocalOutgoingServerSession: OS - TLS negotiation with jabber.org was successful &nb sp; 2008.05.12 06:12:45 LocalOutgoingServerSession: OS - Error, no SASL mechanisms were offered by jabber.org &nb sp; 2008.05.12 06:12:45 LocalOutgoingServerSession: OS - Going to try connecting using server dialback with: jabber.org &nb sp; 2008.05.12 06:12:45 ServerDialback: OS - Trying to connect to jabber.org:5269(DNS lookup: jabber.org:5269) &nb sp; 2008.05.12 06:12:55 ServerDialback: OS - Connection to jabber.org:5269 successful &nb sp; 2008.05.12 06:12:55 ServerDialback: OS - Sent dialback key to host: jabber.org id: 3409094653 from domain: jabber.wolfbeast.com &nbsp ; 2008.05.12 06:12:59 Connect Socket[http://addr=/208.68.163.214,port=39719,localport=5269

http://addr=/208.68.163.214,port=39719,localport=5269] & nbsp; 2008.05.12 06:13:02 ServerDialback: RS - Received dialback key from host: jabber.org to: jabber.wolfbeast.com &nbsp ; 2008.05.12 06:13:02 ServerDialback: RS - Trying to connect to Authoritative Server: jabber.org:5269(DNS lookup: jabber.org:5269) &nb sp; 2008.05.12 06:13:06 ServerDialback: RS - Connection to AS: jabber.org:5269 successful &nb sp; 2008.05.12 06:13:06 ServerDialback: RS - Asking AS to verify dialback key for id6d7daf8c &nb sp; 2008.05.12 06:13:07 ServerDialback: RS - Key was VERIFIED by the Authoritative Server for: jabber.org &nb sp; 2008.05.12 06:13:07 ServerDialback: RS - Closing connection to Authoritative Server: jabber.org &nb sp; 2008.05.12 06:13:07 ServerDialback: RS - Sending key verification result to OS: jabber.org &nb sp; 2008.05.12 06:13:07 ServerDialback: AS - Verifying key for host: jabber.org id: 3409094653 &nb sp; 2008.05.12 06:13:07 ServerDialback: AS - Key was: VALID for host: jabber.org id: 3409094653 &nb sp; 2008.05.12 06:13:14 ServerDialback: OS - Validation GRANTED from: jabber.org id: 3409094653 for domain: jabber.wolfbeast.com

I get the same SubjectAltName error on my own certificate that was supplied by XMPP in the same way.

Incoming server connection (error log):

2008.05.12 01:00:48 [org.jivesoftware.openfire.net.SocketReadingMode.negotiateTLS(SocketReadingMode .java:77)

&n bsp; ]Error while negotiating TLS:

&n bsp; org.jivesoftware.openfire.net.SocketConnection@c5294d socket:

&n bsp; Socket[http://addr=/194.109.23.90,port=56318,localport=5269

http://addr=/194.109.23.90,port=56318,localport=5269] session:

&n bsp; org.jivesoftware.openfire.session.LocalIncomingServerSession@1066d88

&n bsp; status: 1 address: jabber.wolfbeast.com/c3fd3030 id: c3fd3030

&n bsp; javax.net.ssl.SSLException: Unsupported record version Unknown-47.115

&n bsp; at com.sun.net.ssl.internal.ssl.EngineInputRecord.bytesInCompletePacket(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(Unknown Source) at javax.net.ssl.SSLEngine.unwrap(Unknown Source) at org.jivesoftware.openfire.net.TLSStreamHandler.doHandshake(TLSStreamHandler.jav a:212) &n bsp; at org.jivesoftware.openfire.net.TLSStreamHandler.start(TLSStreamHandler.java:158) &n bsp; at org.jivesoftware.openfire.net.SocketConnection.startTLS(SocketConnection.java:1 66) &nbsp ; at org.jivesoftware.openfire.net.SocketReadingMode.negotiateTLS(SocketReadingMode. java:74) at org.jivesoftware.openfire.net.BlockingReadingMode.readStream(BlockingReadingMod e.java:127) &nb sp; at org.jivesoftware.openfire.net.BlockingReadingMode.run(BlockingReadingMode.java: 63) &nbsp ; at org.jivesoftware.openfire.net.SocketReader.run(SocketReader.java:120) &nbs p; at java.lang.Thread.run(Unknown Source)

debug log for the same:

2008.05.12 01:00:48 Connect Socket[http://addr=/194.109.23.90,port=56318,localport=5269

http://addr=/194.109.23.90,port=56318,localport=5269]

&n bsp; 2008.05.12 01:00:49 Connect Socket[http://addr=/194.109.23.90,port=59780,localport=5269

http://addr=/194.109.23.90,port=59780,localport=5269] & nbsp; 2008.05.12 01:00:49 ServerDialback: RS - Received dialback key from host: jabber.xs4all.nl to: jabber.wolfbeast.com &nbsp ; 2008.05.12 01:00:49 ServerDialback: RS - Trying to connect to Authoritative Server: jabber.xs4all.nl:5269(DNS lookup: jabber.xs4all.nl:5269) &nb sp; 2008.05.12 01:00:49 ServerDialback: RS - Connection to AS: jabber.xs4all.nl:5269 successful &nb sp; 2008.05.12 01:00:49 ServerDialback: RS - Asking AS to verify dialback key for id88391ee6 &nb sp; 2008.05.12 01:00:49 ServerDialback: RS - Key was VERIFIED by the Authoritative Server for: jabber.xs4all.nl &nb sp; 2008.05.12 01:00:49 ServerDialback: RS - Closing connection to Authoritative Server: jabber.xs4all.nl &nb sp; 2008.05.12 01:00:49 ServerDialback: RS - Sending key verification result to OS: jabber.xs4all.nl &nb sp; 2008.05.12 01:00:49

&n bsp; 001077 (01/03/00) - #3 registered a statement as closed which wasn't

&n bsp; known to be open. This could happen if you close a statement twice. & nbsp; 2008.05.12 01:00:49 Connection closed before session established

&n bsp; Socket[http://addr=/194.109.23.90,port=56318,localport=5269

http://addr=/194.109.23.90,port=56318,localport=5269] & nbsp; 2008.05.12 01:11:23

&n bsp; Logging off jabber.xs4all.nl on

&n bsp; org.jivesoftware.openfire.net.SocketConnection@1011f1f socket:

&n bsp; Socket[http://addr=/194.109.23.90,port=59780,localport=5269

http://addr=/194.109.23.90,port=59780,localport=5269] session:

&n bsp; org.jivesoftware.openfire.session.LocalIncomingServerSession@122f17b

&n bsp; status: 1 address: jabber.xs4all.nl id: 88391ee6

I'm not sure if the incoming server connection error is a problem my end or a problem at xs4all. And I'm not a java programmer so I have no clue about most of these statements here...

Some help appreciated!

Mark.

alex.ferguson@navy.mil — Thu, 01 Jan 1970 00:00:00 GMT

Does anyone know of a problem with the Open Fire server not handling PKI certificates correctly. I'm just starting to get into this (newbie) and could use some help. I've been told that if you're trying to authenticate with PKI, the client handles it correctly....but you can put an expired certificate on the server and when the server tries to authenticate, it will still work with an expired certificate.

Anyone know if this is true or not or have any experience with PKI authentication?

Alex

webmaster@jivesoftware.com — Thu, 01 Jan 1970 00:00:00 GMT

I have been trying for about 1 day to get Openfire set up with SSL but have not succeeded. I am not a novice yet I am just unable to set it up. Here is what I have right now:

1. My domain is "im.spinaxys.com"

2. Decrypted private key in PEM format

BEGIN RSA PRIVATE KEY-----

0DDqOMbM6JWGZigMsUIjFfZgi9bIQItifQpRmiOmh9fFS4nKXfFtAyc1bKANALQs

END RSA PRIVATE KEY-----

3. Wild card signed certificate for "*.spinaxys.com" in PEM FORMAT

BEGIN CERTIFICATE-----

MIIINzCCBx+gAwIBAgIDAathMA0GCSqGSIb3DQEBBQUAMIG2MQswCQYDVQQGEwJJ

END CERTIFICATE-----

4. CA (http://cert.startcom.org/) root certificate in PEM format (I believe this CA is already part of openfire trusted CAs)

BEGIN CERTIFICATE-----

MIIFFjCCBH+gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBsDELMAkGA1UEBhMCSUwx

END CERTIFICATE-----

5. CA intermediate certificate

BEGIN CERTIFICATE-----

MIIHdzCCBuCgAwIBAgIBAjANBgkqhkiG9w0BAQQFADCBsDELMAkGA1UEBhMCSUwx

END CERTIFICATE-----

I guess this is all that is ever needed to set up SSL support for a server. I must have read atleast a zillion documents trying to achive this but to no use :).

I would be really grateful if anyone could give step by step instructions on how to set up SSL in openfire with the above files. Thanks !!!

kate223@gmail.com — Thu, 01 Jan 1970 00:00:00 GMT

I'm new to the openfire/spark community. I was wondering if someone could explain to me how the chats are encrypted. When I read the SSL documentation for openfire, step 6 talks about importing the client certs into the truststore. I need to do that before the chats are encrypted? How can I possibly know who all my clients are to import all their certs? I need someone to help me understand the process better.

pkeser@stanford.edu — Thu, 01 Jan 1970 00:00:00 GMT

I am settiing up a proof of concept OpenFire 3.45 server running on Ubuntu Gutsy. Before we integreate with our LDAP & Shibboleth infrastructure I need to find a configuration that if the server certificate changes the client will notify the user of the change in certificate.

When I used Spark or Pidgin I connect fine but when I change the cert it still connects and there is no indication of a change in cert. When I use https to connect to the management interface I do see a warning about the change in cert. I tried using PSI and as soon as I turn on SSL PSI breaks.

Finally I tried using SparkWeb and I get a 404 error:

HTTP ERROR: 404

NOT_FOUND

RequestURI=/

Powered by Jetty://

I am new to OpenFire and previously have only used Jabber/Pidgin as a user. Any suggestions and troubleshooting tips would be greatly appreciated. This is not in production so I have no problem running 3.5rc1 if that would make any difference.

Thanks

-PaulK

webmaster@jivesoftware.com — Thu, 01 Jan 1970 00:00:00 GMT

Trying to get a SSL cert from ipsca to load into openfire. Used keytool to add the ipsca intermediate cert into truststore. Restarted services and had openfire create signed request. Sent to ipsca the RSA and received reply back with cert. Pasted certificate authority reply and get the error:

An error occured while importing the Certificate Authority reply. Verify that the reply is correct and that it belongs to the correct certificate

Any help would be great as we are trying to implement this with our work request system which is already on SSL!!!

Thanks

Pat

akrherz@iastate.edu — Thu, 01 Jan 1970 00:00:00 GMT

Greetings,

My ignorance is probably to blame here, but I can not seem to get my GeoTrust signed SSL cert to work with Openfire 3.4.4 . I have two files in my possesion, one that is topped with '--~~-BEGIN CERTIFICATE-' and the other with '-BEGIN PRIVATE KEY~~---'. (I got this cert from my web hoster).

So, if I import this cert via the admin console, Openfire takes it, but then firefox can't connect to the console complaining about corrupt cert or no supported algorithms found. Hmmmm.

So then I try the manual keytool method and get tracebacks.

When I try to import the private key and cert via the console, I get tracebacks

java.lang.NullPointerException

at org.jivesoftware.util.CertificateManager.installCert(CertificateManager.java:50 1)

The key and cert work as expected with Apache. I must be missing some step.

(Looking my post last year about this problem, I see I was able to do a hack with keytool, but this never resulted in a cert that openfire thought was valid).

thanks,

daryl

support@sjobeck.com — Thu, 01 Jan 1970 00:00:00 GMT

All kidding aside, I can not establish a secure connection from latest stable iChat, using a proven working, good, internal jabber account on our openfire server, to our internal server running centOS 4.5, all updates, and openfire 3.3.3.

I believe that I have tried every possibility of the security settings and none work. Turns out we actually havent been using iCaht much but now have the need for it. We have been using Adium or Spark on most of our client's machines for the last year or so, but .... here is the thing, I know for a fact that I did test this scenario about a year ago, whatever version of wildfire that that was, and it worked. I woder what is different today, sure lots has changed, but dont know which side has changed in such a way as to not allow this to work. I tried connecting to ports 5222 & 5223 in lots of configurations inside iChat.

Any insight from someone who has this working is most appreciated.

Completely off the topi, is anyone using iChat with openfire & using the video (ie: iSight) during their chat? I am headed to Asia for a while & I really need to

get video cracking & really prefer that that video stay secure & internal.

Thanks so much.

Cheers.

Jason Sjobeck

sjobeck.com

michael@nqmining.com.au — Thu, 01 Jan 1970 00:00:00 GMT

Problem:

I want to be able to communicate with an Openfire server using SSL. The Server must be able to prove that they are who they say they are, so that you can trust that any communications going on are secure.

Solution:

Operate Openfire over TLS using signed server certificates. This entails having a matched public/private key pair to encode all transactions. All Openfire users will encode their communications using your public key. These encoded transmissions will then only be able to be decoded with your private key. If you have your public key certified by a trusted authority (a Certificate Authority) then Openfire clients can trust that their connections with your Openfire server are secure.

Instructions:

To get this Signed Certificate on your Openfire server, you'll need three things:

1) A public/private key pair to encrypt/decrypt messages

-You will generate this yourself as a Certificate Signing Request which you will then have signed by your chosen Certificate Authority (CA) and an associated private key

2) A certificate for your server signed by an external CA (Certificate Authority)

-You will have to request this from a CA of your choosing using your CSR

3) The public certificate of your CA

-This will be freely distributed by your CA, and might also require a certificate chain containing the certificates for all the higher level (root) CA's that have authorized your CA.

One you have these three things, you'll need to import them into Openfire.

The following steps will guide you through the process of obtaining and then importing your certificates:

Step 1: Generating a CSR & Private Key

You can generate a CSR / Private key pair using the tool of your choice. There are many free tools available online (an example) or you could use the Java keytool to generate a CSR. Be warned, if you generate a CSR with the keytool the private key will be kept in the tool, so take care to read the keytool documentation and only generate a CSR once to make sure that your CSR and Private Key match.

Whatever tool you use, keep a copy of both the CSR and the Private key, and be sure to keep them matched -- you'll need the private key for your specific CSR when you get your signed certificate.

Pending bugs JM-1140 and JM-1139 it will be possible to create a CSR and private key pair in Openfire.

Step 2: Getting Your Signed Certificate

This step will involve deciding upon a Certificate Authority, and likely paying your chosen CA to have your certificate request signed.

You will send your generated CSR to your chosen CA (keep the private key to yourself.) The CA will send you in reply two things: A signed copy of your certificate, and their public certificate which may their own cert as well as their certificate chain or just their cert.

Step 3: Making Openfire Recognize Your CA

Using the java keytool, you will need to add your CA's certificate to the openfire truststore (located in <<openfire dir>>\resources\security.) The keytool command to import your CA certs into your truststore is roughly as follows:

keytool -import -alias <<CA alias>> -file <<CA cert file>> -keystore <<openfire dir>>\resources\security\truststore

You will need to execute this command once for each certificate file sent to you by your CA.

Step 4: Importing Your Signed Certificate into Openfire

If you created your certificate request and private key using the built-in openfire tool, then importing the signed certificates is a simple matter of putting the signed cert in the "Certificate Authority Reply" box in the Server Certificates interface in the admin console.

For more information see the Java keytool documentation.

If you created your certificate request and private key with the java keytool, you will need to import the CA reply into the Openfire keystore (<<openfire dir>>\resources\security\keystore) using the same method as importing your CA's certificate in step 3.

If you created your certificate request and private key with an external tool, you will be able to import these through a hidden interface in the openfire admin console: <<admin url>>/import-certificate.jsp. Just navigate to that page, paste your signed certificate and private key into the appropriate boxes, and click save.

Step 4a Importing certificate from a Certificate installed in Windows, Extracting Private Key from a currently installed certificate by exporting to PFX file

If you received a certificate from your provider, installed it on your windows system and have no idea what a private key is then these instructions should hopefully help.
If you already have a certificate backup (PFX file) skip step 1 otherwise first we need to create a Full Backup which includes a Private Key
Step 1
1.) Start > Run
2.) Type in MMC and click OK
3.) Go into the File Tab > select Add/Remove Snap-in...
4.) Click on Add > Double Click on Certificates and click on Add > OK
5.) Select Computer Account
6.) Select Local Computer
7.) Click the + to Expand the Certificates Console Tree
8.) Look for the Personal directory/folder and expand Certificates.
9.) Right Click on the Certificate you would like to backup and choose > ALL TASKS > Export
10.) Follow the Certificate Export Wizard to backup your certificate to a .pfx file
11.) Choose to 'Yes, export the private key'
12.) Choose to include all certificates in certificate path if possible. (do NOT select the delete Private Key option)
13.) Leave default settings > Enter a password of your choice
14.) Choose to save file on a set location (something easy like c:\mycert.pfx)
15.) Finish
16.) You will receive a message > Export Successful
17.) The .pfx file backup is now saved in the location you specified
Step 2
Now you will need OpenSSL compiled binary from windows, easiest I have found is:
http://www.slproweb.com/products/Win32OpenSSL.html
by default this is installed into "c:\openssl"
you now need to run this command to extract the details required to import into OpenFire
c:\openssl\bin\openssl.exe pkcs12 -in c:\mycert.pfx -out c:\outputfile.txt -nodes
(where c:\mycert.pfx is the location of the exported certificate of the previous step)
If you open up the outputfile, this contain the certificate and well at something like this:
-
BEGIN RSA PRIVATE KEY---
(Block of Random Text)
-
END RSA PRIVATE KEY-
Step 3
Open up the <<Openfire admin url>>/import-certificate.jsp
Pass Phrase: enter the password you used when creating the Backup file in the 1st step
Private Key: enter this section from the output file (including the BEGIN and END lines):
-
BEGIN RSA PRIVATE KEY-
(Private Key Content)
-
END RSA PRIVATE KEY-
Certificate Content: enter this section from the outfile (including the BEGIN and END lines):
-
BEGIN CERTIFICATE-
(Certificate Content)
-
END CERTIFICATE---
Click Save and your certificate should now be available in Openfire.

You will now be able to communicate in openfire through a trusted TLS connection.