Red5, http bind with ssl

I am struggling a bit to find out any information about the problem I am having. I have the red5 plugin working on the http bind port of 8080 but I would like to get it working on SSL. In the openfire http bind setting page I have tried setting the ssl port to 8443 but when red5 is running I get this:

Error creating bean with name ‘rtmpt.server’ defined in class path resource [red5-core.xml]: Invocation of init method failed;

as well as several net.BindAddress errors in my openfire warn.log:

2008.09.08 00:35:56 failed SelectChannelConnector@ Address already in use
at Method)

In the openfire error log I get this repeating several times after I try and set the ssl port in the openfire web interface:

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘Server’ defined in class path resource [red5-rtmpt.xml]: Invocation of init method failed; nested exception is Address already in use
Caused by: Address already in use
at Method)

Digging through the source code of the bean with id=“rtmpt.server” (red5-core.xml) is this:

Server rtmptServer = (Server) appCtx.getBean("Server");

si it looks like the 'server' bean is the root of the problem.

I have tried changing the bean with id=“server” port values but it didn’t help.

The port does get set in the openfire database under the key but it is always ‘0’ after I reboot openfire in the web interface.

I can see in the red5-rtmpt.xml file that there is a section to uncomment for SSL. I haven’t done that and I am a littel unsure of what I am doing so any advice would be appreciated.

If I remove the red5 plugin everything seems to go OK but I am unsure how to prove that. I can hit localhost:8443 and be given a 404 which is what I would expect without red5 running.

Could anyone please provide any suggestions or hints?

I am pretty sure that the ‘address already in use’ message means that you are attempting to use the same port for two different things. I had a similar problem when attempting to start openfire and found that I was trying to use the same port for client login as was already assigned for flash cross domain. Sounds like you have already checked some of this out but if things work without the red5 plugin it seems to me that it (red5) is trying to using a port that openfire may already be using for something obscure. Hope this helps or jogs some random ideas anyway.

HI and thank you for replying.

You mention something about the flash cross domain, could you expand on where that is set? I am very new to openfire and red5 and so am happy to look at all the possibilities.

I agree that the message means that the port is already in use but I am finding it difficult to find out how to fix it. If I check:

sudo netstat -antp | grep 8000

Then I get:

tcp 0 0* LISTEN 5882/java

and ps -A | grep java gives:

5882 ? 00:01:20 java

so that would mean there is only 1 java process runing on the machine and it has port 8000. That java process must be openfire and so it seems like openfire already has the port it is trying to get. As it already has it and then tries to get it again it fails. I don’t know if that is actually what is happening but I can’t think of another explaination at the moment.

Does anyone know how I can prove that the ssl port is set up correctly if I remove red5? As I mentioned earlier I can hit localhost:8443 without red5 running but it gives a 404. Is that the normal behaviour which indicated that ssl is enabled?

If you have any other suggestions then I would be happy to hear them as at the moment I am at a total loss as to what to try next.


Frankly I don’t know what the flash cross domain is either but you can see it under server information on the server manager tab in the admin console. I don’t know where it is set and it is probably a default since I didn’t set it. It doesn’t matter if java isn’t using your port it could be another process. I would do a sudo netstat -l to see all the ports that are being listened on, it’s probably something else using your port. You may want to try this when you have red5 installed and when you don’t to see what changes. I have also found nmap to be helpful when I want to know what ports I have available and what is running on them. for example running nmap against my localhost ( gives me this result; ( i ran a port scan -sS against myself for ports ranging 1 thru 10000 -p 1-10000)

[root@linux10 sparkweb]# nmap -sS -p 1-10000

Starting nmap 3.70 ( ) at 2008-09-08 13:35 EDT
Interesting ports on localhost.localdomain (
(The 9981 ports scanned but not shown below are in state: closed)
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open rpcbind
443/tcp open https
631/tcp open ipp
3306/tcp open mysql
4750/tcp open unknown
5222/tcp open unknown
5223/tcp open unknown
5225/tcp open unknown
5229/tcp open unknown
5269/tcp open unknown
7070/tcp open realserver
7443/tcp open unknown
7777/tcp open unknown
9090/tcp open zeus-admin
9091/tcp open unknown

Nmap run completed – 1 IP address (1 host up) scanned in 6.680 seconds

This gives you a lot of info as to what is running on what ports on your machine. again you may wish to run this when red5 is installed and again when it isnt. nmap can be found at

hope this helps

Thanks again for taking the time to answer.


I ran the ‘nmap -sS -p 1-10000’ command that you mentioned and got:

Not shown: 9965 closed ports
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open rpcbind
113/tcp open auth
139/tcp open netbios-ssn
143/tcp open imap
443/tcp open https
445/tcp open microsoft-ds
631/tcp open ipp
712/tcp open unknown
783/tcp open spamassassin
801/tcp open device
993/tcp open imaps
1935/tcp open rtmp
2049/tcp open nfs
2208/tcp open unknown
2812/tcp open unknown
3306/tcp open mysql
3690/tcp open unknown
4949/tcp open unknown
5222/tcp open unknown
5223/tcp open unknown
5229/tcp open unknown
5269/tcp open unknown
6010/tcp open unknown
6600/tcp open unknown
7741/tcp open unknown
7777/tcp open unknown
8000/tcp open http-alt
8080/tcp open http-proxy
8099/tcp open unknown
9091/tcp open unknown
10000/tcp open snet-sensor-mgmt

Nmap finished: 1 IP address (1 host up) scanned in 0.605 seconds

Then I ran ‘sudo lsof -ti :8000’ and got back 5882 which is the same process id as the only java process running on my box. When I kill that java process and try the nmap command again and the:

8000/tcp open http-alt

from the previous nmap command is gone. That would mean that openfire has port 8000 open.


The nmap command shows that port 8000 is not in use.


The Red5 plugin uses port 8000.


Would you agree with my thinking or am I doing something silly?

In all of this, port 8003 is never used even though it is specified in the openfire/plugins/red5/WEB-INF/classes/red5-rtmpt.xml file right alongside port 8000. This is the snippet from the file:

I wonder if that means that port 8003 should be the one that openfire ‘connects’ its HTTP_BIND ssl port to but for some reason Red5 tries to open port 8000 for that connection rather than 8003 (therefore throwing the net.BindException)? Eeeek, I don’t fancy trying to prove that and right now I am not quite sure my logic is correct there.

Does anyone else have Openfire (3.6.0), Red5-plugin and the http_bind ssl port all set and working together?

I would agree with what your thinking. If I remember right anytime that openfire had a port conflict it just would not let me in at all even if the conflict was not I the port I was trying to use. I have to make sure that none of my ports conflicted. I hope I have helped but I am afraid you have reached the limit of my useful information. Good luck to you.

That’s OK, thanks for replying. You have helped stimulate my thinking and maybe something will drop out of it eventually.

As far as I can tell this is a bug in openfire 3.0.6a. I have done a complete re-install of openfire and even after the default install I cannot set the http_bind ssl port. Every time I try (without red5), it looks like it has worked but I have no way of testing it - I kow that when I go the URL (localhost:8443) I am not presented with a certificate. If I reboot openfire and look at the settings again then the ssl port is always set to ‘0’. I have also downloaded the source code and tried it on my local machine (rather than the server) - same problem.

Can someone answer the following questions?

  1. The SSL certificates that come with openfire by default allow the http_bind ssl port to work?

  2. Do you have a working openfire 3.0.6a with http_bond ssl?

The only clue I have seen is a null pointer that occurred only once. I don’t have a record of it but it was in:


Of course, that may have been a one off.

I have this fixed now, for me at least. I have had to edit the source code and recompile. The class I edited was:


which is inside of openfire.jar. I edited this method:

configureHttpBindServer(int port, int securePort)

and the changed line was:

Connector httpsConnector = createSSLConnector(securePort);


Connector httpsConnector = createSSLConnector(8443);

I have attached my edited file in case anyone else needs it but there are a couple of System.out.println in there and the fix will force you to use 8443 as the http_bind ssl port. Making changes in the admin interface or the database will most likly have either no effect or an undesirable one. It seems that the edit may make it impossible to log into the admin console without using the secure connection port (9091).
openfire.jar (6417424 Bytes)