Wowza Community

Wowza Not Binding to SSL Port

Hi I have a bit of a problem here. I went ahead and installed our SSL certificate onto our server. by clicking on that link. It should produce the wowza default page on the https:// connection. In fact if I put this into internet explorer or into firefox, I appear to make a successful connection on port 443 by using if I load a playlist in ie or ff, they are downloaded, I can see they are accessing which appears to be the port that SSL has binded too.

However, when I try to open the https:// url inside of chrome or any type of video player embeded into the page, I cannot connect to the SSL socket at all. There is no errors in the logs. according to firefox and internet explorer the certificate that is set up on the domain is correct. I used these instructions here and go the certificate installed on the server. I’ve already been through the keytool a million times and their does not appear to be any problem with the certificate. I did however, find a thread that says to add something like this into Application.xml for one of the apps.




Adding or removing this value makes little difference.

[HTML]netstat -tulp | grep https

tcp 0 0 *:https : LISTEN 6186/java [/HTML]


[HTML]netstat -tulpn | grep 443

tcp 0 0* LISTEN 6186/java [/HTML]


[HTML]netstat -tulpn | grep 1935

tcp 0 0* LISTEN 6186/java [/HTML]


[HTML]netstat -tulp | grep http

tcp 0 0 ds6880.dreamservers:www : LISTEN 5836/httpd-argon-ht

tcp 0 0 *:https : LISTEN 6186/java[/HTML]

Also when I point to this domain and I type in and use 443 certificate appears valid. Like I am returning in Firefox and Chrome. This test works on Chrome.

When I do this test it is failing with about the same problem I am describing.

Anyone have any ideas why the SSL is not working? Your help would save me a lot of time and money.

Thank You, John Anderson

Hi, I solved my own problem. It appears that there was a problem with the SSL handshake. Proved to not be a problem on some systems. However, changing the iptables on my server worked wonders. This is one of those servers where some people have access to it through a control panel, some people have access to it through the bash shell. I use the server from the Bash Shell and people with access to the server through the default control panel can over ride each others settings. There was a hidden set of iptables rules that was causing the server to reject certain requests to it.

So simply flushing the[HTML] iptables -F[/HTML] then [HTML]iptables-restore /root/rules.bak[/HTML] worked wonders from this job. So I will just leave this posted for the next guy, with a similar problem.

Sorry for the oversight. There was a DNS problem with StreamLock, which has been resolved. I hope that resolved this problem. Let me know otherwise.


Actually I spoke too soon, what I am noticing is that I am able to view the engine in https if I have Fiddler Web Debugger turned on and handling the ssl. If I shut it off and let chrome try to do it the problem still happens.

I tried using one of the StreamLock certificates that does not work either. Still have the same problem in Chrome. In Internet Explorer it shows TLS 1.0, AES with 128 bit encryption (High); RSA with 2048 bit exchange as for the java information on the server its as follows.

Java Version


Java VM Version


Java Architecture


Java Name

Java HotSpot™ 64-Bit Server VM

Java Vendor

Sun Microsystems Inc

Any suggestions