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:
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?
See my reply here:
Yep. I got it.
The problem stems from the fact asking for https://YOUR_LB redirects to http://YOUR_APACHE_NODE.
Your LB should have the X_FORWARDED_PROTO header set to https when passing the request along to your Apache nodes. In the Apache main config [/opt/kaltura/app/configurations/apache/kaltura.conf], there is this line:
and in turn, all the code looks for the HTTPS header to determine whether or not the protocol should be HTTPs.
Also, in /opt/kaltura/app/configurations/local.ini and…
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, :
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?
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:
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";
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.
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:
LoadModule ssl_module modules/mod_ssl.so
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
<IfVersion < 2.4>
Mutex sysvsem default
SSLProtocol all -SSLv2
CustomLog /opt/kaltura/log/kaltura_apache_access_ssl.log vhost_kalt
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, thanks for that tip, I was going to try something like that too since we have had the main server as SSL before.
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.
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:
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.
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.
Thanks for your help, I finally go to the stage where I’m getting that URL changed and fine tuning the delivery profile.