Secure Proxy of HTTP Kaltura

Community Forums Backend Server Support
1

I would like to proxy our Kaltura off of another server running SSL, and it works fine for the administration interface, but when I go to the content admin page goes to load I get a couple calls to the server in the pages:

<script type=“text/javascript” src=“http://kaltura.willamette.edu/lib/js/jquery-1.8.3.min.js”></script>
<script type=“text/javascript” src=“http://kaltura.willamette.edu/lib/js/swfobject_v2.2.js”></script>

All of these get blocked since they are coming from an insecure server. Is there a config setting I can change so those get the correct server name or some way that would make them relative so I could proxy them?

Bill K.

2

Hi @bkelm,

See my reply here:

3

So Jess, I have that in my zzzkaltura.conf, and I’m proxying and even have the URL rewritten to the proper server libmedia is our SSL server we want to proxy from, this is running on our kaltura server, but since these calls are for http, and not https, :

<script type=“text/javascript” src=“http://libmedia.willamette.edu:443/lib/js/jquery-1.8.3.min.js”></script>
<script type=“text/javascript” src=“http://libmedia.willamette.edu:443/lib/js/swfobject_v2.2.js”></script>

I still get the mixed content error:

kmc#content|manage:1 Mixed Content: The page at ‘https://libmedia.willamette.edu/index.php/kmc#content|manage’ was loaded over HTTPS, but requested an insecure script ‘http://libmedia.willamette.edu/lib/js/jquery-1.8.3.min.js’. This request has been blocked; the content must be served over HTTPS.

Is it possible to get those two calls to be for https?

Bill K.

4

Hi @bkelm,

Did you verify that the X_FORWARDED_PROTO header is correctly set by the LB?
If you’ll look at /opt/kaltura/app/alpha/apps/kaltura/templates/kmclayout.php, you’ll see:

<script type="text/javascript" src="<?php echo requestUtils::getCdnHost( requestUtils::getRequestProtocol() ); ?>/lib/js/swfobject_v2.2.js"></script>

requestUtils::getRequestProtocol() is defined in /opt/kaltura/app/alpha/apps/kaltura/lib/requestUtils.class.php:


        public static function getRequestProtocol()
        {
                $protocol = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') ? "https" : "http";
                return $protocol;
        }

The HTTPS header should be set to “on” in the event X_FORWARDED_PROTO is set. That’s because of this config in /opt/kaltura/app/configurations/apache/kaltura.conf:

# for SSL offloading support, if LB has X_FORWARDED_PROTO set to 'https', set HTTPS to 'on'
SetEnvIf X-Forwarded-Proto https HTTPS=on

You didn’t specify what Kaltura CE version you are using, if it is very old, perhaps you are missing that SetEnvIf directive, in which case, you should add it and reload Apache.

5

Hi @bkelm,

This is what we do in Calipso to properly proxy https to Kaltura CE with nginx.

We just add this file zzzkaltura.ssl.conf and restart apache:

<IfModule !ssl_module>
LoadModule ssl_module modules/mod_ssl.so
Listen 443

SSLPassPhraseDialog builtin
SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
<IfVersion < 2.4>
SSLMutex default

= 2.4>
Mutex sysvsem default

SSLCryptoDevice builtin

SSLCertificateFile /etc/ssl/certs/webcloudvideo.crt
SSLCertificateKeyFile /etc/ssl/certs/webcloudvideo.key
SSLCACertificateFile /etc/ssl/certs/ca-bundle.crt
<VirtualHost *:443>
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

ErrorLog "/opt/kaltura/log/kaltura_apache_errors_ssl.log"
CustomLog /opt/kaltura/log/kaltura_apache_access_ssl.log vhost_kalt

Include "/opt/kaltura/app/configurations/apache/conf.d/enabled.*.conf"

We forward all headers as Jess told you and Kaltura understands and generates the correct URLs.

You can see a self-signed cert for Apache but it’s only to let it start without errors. The proxy servers should have the real certificates.

Hope this helps,

David Eusse

6

David, thanks for that tip, I was going to try something like that too since we have had the main server as SSL before.

7

It seems that I cut the config file and is incomplete but I guess you got the idea. Just close the tags for the virtualhost.

Regards

8

David, so maybe this is what you are accounting for, we get everything to be proxied fine, except the media file. It still makes a call to the Kaltura server at https:

GET https://kaltura.willamette.edu/p/101/sp/10100/serveFlavor/entryId/0_35egj56h/v/2/ev/2/flavorId/0_p6wdhwzm/forceproxy/true/name/a.mp4 0 ()

Where if it made that call with the proxied URL it plays just fine.

9

Hi @bkelm,

We use a delivery profile for the media files. The delivery domain might be different from the Kaltura API/web domain and points to the proxy servers (CDN).

The CDN pulls the files from the nginx VOD segmenter as configured in Kaltura.

BTW, that allows us to use one Kaltura backend for different delivery CDNs or domains.

For instance, we define an HLS delivery profile (apple_http, vod_packager_hls) as this:

http://hd.mykaltura.domain/hls pulling from the kaltura_nginx backend port 88

We stopped using progressive download since HLS works very, very well for most clients.

Try this and let me know.

regards,

David

10

Still trying to determine what sets where the video is called from, as everything is proxied fine here:

https://libmedia.willamette.edu:8443/index.php/extwidget/preview/partner_id/101/uiconf_id/23452776/entry_id/0_i7b5mcph/embed/auto?&flashvars[streamerType]=auto

but the video itself when it goes to load it calling this:

https://kaltura.willamette.edu/p/101/sp/10100/serveFlavor/entryId/0_i7b5mcph/v/2/ev/2/flavorId/0_n9giel81/forceproxy/true/name/a.mp4

I will tweak more with the publishing profile, but no success with that changing that call yesterday.

11

David,

Thanks for your help, I finally go to the stage where I’m getting that URL changed and fine tuning the delivery profile.