Hey all. Long time, no talk. I hope you’re doing well.
I have a Kaltura 13-ish cluster that was set up with no SSL. I am now going to SSL enable it. The strategy I’m using is to use SSL offloading at the bigip load balancers we have instead of configuring SSL on every front end node. This seems to be set up correctly and now I need to reconfigure the front ends to refer to themselves as being behind the SSL offloading LB.
I know I need to change the delivery profiles in the database. However, as far as front end config I have an ans file, but am unsure what I should change in this scenario. I believe i do need to change SERVICE_URL to https, but what about PROTOCOL? I don’t think the IS_NGINX_SSL or IS_SSL should be Y because the kaltura install itself isn’t SSL enabled.
I think I should just have to re-run kaltura-front-config again after modifying the ans, but do I need to run kaltura-base-config as well? I can’t recall.
I am going to just try it and see if it works, but I thought I’d ask the pro’s as well
David, we do a similar thing at our site, below are some of the important answers I have to questions and a note I have about a change we have to make at the end. So libmedia is our front facing ssl server, and kaltura is behind the scenes.
Here’s notes on how to configure Kaltura behind our TLS proxy (libmedia:8443)
The CDN host setting should be libmedia.willamette.edu:8443. Within the local.ini file, this will set cdn_host and cdn_host_https.
The answer to “Your Kaltura Service URL” should be https://libmedia.willamette.edu:8443. Within the local.ini file, this will configure several URLs to use the proxy. An entry for the service URL is also added to system.ini.
The answer to “Apache virtual hostname” would ideally be set to libmedia.willamette.edu:8443, the answer to “Vhost port to listen on” would be “80”, the answer to the later question “Is your Apache working with SSL?[Y/n]” would be NO. HOWEVER, as noted above, the virtual hostname cannot contain a port number (because the “:” breaks the monit configuration script). The solution is to set the hostname to “kaltura.willamette.edu” and then update local.ini as described. Most URLs in local.ini are configured using the virtual hostname. The virtual hostname is ALSO added to /opt/kaltura/app/configurations/system.ini; it is ok (apparently) to leave this setting as “kaltura.willamette.edu.” The system.ini setting is not involved in constructing URL paths…and the actual hostname may be required (or at least sensible) in the system configuration.
We do not configure the host to use SSL. But we do proxy through a TLS/SSL server (libmedia:8443).
These are the values we set in the system.ini file:
Thanks @bkelm! It seems we are on the same page, although I am having a hard time with apache and the admin console or really anything else. I’m figuring this out in our dev environment and I’m getting an API error right off the bat:
2019-09-06 20:23:58 [0.079452] [22115722] [8] [%context%] [ErrorController->errorAction] ERR: exception ‘Kaltura_Client_ClientException’ with message ‘Peer certificate cannot be authenticated with known CA certificates. RC : 0’ in /opt/kaltura/app/admin_console/lib/Kaltura/Client/ClientBase.php:942
I’ve not run into this before.
Also, are you using nginx at all? I need to get that configured as well. I’ve found some forum posts from @jess about configuring nginx that should set me straight.
Alright, I found a thread that talked about uncommenting this line in admin.ini
settings.clientConfig.verifySSL = false
I did that and I got the admin console to come up. however, when trying to manage a publisher, the browser is not happy about some non https links in the page
Mixed Content: The page at 'https://kaltura-dev.intranet.hdr/index.php/kmc/kmc4' was loaded over HTTPS, but requested an insecure script 'http://kaltura-dev.intranet.hdr/lib/js/jquery-1.8.3.min.js'. This request has been blocked; the content must be served over HTTPS.
kmc4:1 Mixed Content: The page at 'https://kaltura-dev.intranet.hdr/index.php/kmc/kmc4' was loaded over HTTPS, but requested an insecure script 'http://kaltura-dev.intranet.hdr/lib/js/swfobject_v2.2.js'. This request has been blocked; the content must be served over HTTPS.
So, somewhere in my config these old http links are being generated. I wonder if this is cached somewhere…
Clearly, requestUtils::getCdnHost( requestUtils::getRequestProtocol() returns the wrong protocol in your case. You can add some control prints to that function to understand why that is.
Thanks @jess. I seem to make the most progress when I post questions
So, I don’t think my LB is setting the right headers to set HTTPS = “on”. if I manually do that in the apache config we’re good. I’ll work with my networking team to get it squared away
Posting questions is definitely a good way to make headway:) While we’re on the subject, cheers to @bkelm for contributing and helping others.
Just to clarify, your LB is not meant to set the HTTPS header to “on” necessarily.
In /opt/kaltura/app/configurations/apache/kaltura.conf, you should see:
SetEnvIf X-Forwarded-Proto https HTTPS=on
And so, your LB should simply set the X-Forwarded-Proto header to https and then the Apache conf will ensure that HTTPS is set to on. This is common practice.
Thanks Jess. It never seems to fail. I can’t figure something out, I post a question, then figure it out a few minutes later
Yes, that’s what I meant but didn’t really explain it correctly. I need the LB to set X-Forwarded-Proto to https so that Apache config included with Kaltura will work.
