I'm preparing to follow the instructions in http://www.centova.com/doc/cast/installation_manual/08_Configuring_SSL - "Installing Your Own Certificate" and have some minor queries that I would appreciate some input on. We're running Centova Cast v3.2.8 on a CentOS 6 system.

1. If I run rpm -qa | grep -i openssl I get  openssl-1.0...x86_64
Do I also need openssl-devel installed?

2. If the setssl command to install the certificate fails for some reason, what do I do to recover (ie get back to where I started)?

Many thanks!
--Richard E

Further to my previous enquiry, we have received our SSL certificate package from Comodo. It consists of two files, our_domain.crt and our_domain.ca-bundle.

our_domain.crt contains a single certificate element and our_domain.ca-bundle three elements.

Should we concatenate these two files (our_domain.crt at the top) ? Or use the ca-bundle file?

What should the filename and extension be?

Thanks,
--Richard E

I am pleased to say that I have successfully installed our SSL certificate and the Centova front-end login is now available securely.

However I am getting a Mixed Content warning from the Centova pages. This appears to be due to the album cover images not being retrieved securely. I am getting data such as the following:

Mixed Content: The page... was loaded over HTTPS, but requested an insecure image 'http://is5.mzstatic.com/image/thumb/Music/v4/ec/45/88/ec458862-fb73-ce21-c1bb-bd6f7e77c325/source/100x100bb.jpg'. This content should also be served over HTTPS.

Mixed Content: The page at... was loaded over HTTPS, but requested an insecure image 'http://is2.mzstatic.com/image/thumb/Music/v4/d4/ae/a9/d4aea955-7987-5080-a274-8962dc7f2290/source/100x100bb.jpg'. This content should also be served over HTTPS.

Mixed Content: The page at... was loaded over HTTPS, but requested an insecure image 'http://is5.mzstatic.com/image/thumb/Music/v4/ec/45/88/ec458862-fb73-ce21-c1bb-bd6f7e77c325/source/100x100bb.jpg'. This content should also be served over HTTPS.

It would appear that these images will display if called with https - how do we tell the system to retrieve the images via SSL?

Thanks!
-_Richard E

Looking into this more deeply, it would appear that when the album is available on iTunes, the script inserts the "buy this album" link AND gets the album cover from is*.mzstatic.com, which it calls with http and not https.

Turning off iTunes as a source for album covers in the appropriate settings does not stop it doing this.

It appears that the is*.mzstatic.com album thumbnails are entirely capable of being called by https, we just need to modify the script to allow it to do so.

Where is it?

Thanks!
--R

Hello Richard E,

The certificate been used at "is5.mzstatic.com" doesn't match the domain name unfortunately (as it is issued to a248.e.akamai.net), this means that even if the images were to be requested via SSL/Https, you will receive a security warning from your web browser anyways, and until that changes, there isn't much we can do.

If you don't want mixed-content warnings been prompted by cover images, you will need to disable all external sources under Settings > Albums, and then purge the media library.


Regards.

Hi, Roger and thanks for your helpful reply.

For the time being, we'll just use the text-only version of the current track widget. We previously used Marci for displaying Now Playing data on the web site, but now we're on Icecast we only get the current track and no history, which is tedious and rather reduces its value, excellent though it is as far as it goes depending on platform.

Is anyone aware of any other third-party Now Playing solutions? I ran some tests with ACRCloud which produced very positive results, but it rather seems overkill to use auto content recognition when we have metadata available most of the time!

While we're at it, here are some comments derived from a parallel support ticket discussion that are pertinent to the resolution of the SSL queries outlined at the start of this topic.

Centova does not require openssl-devel to be installed

Wildcard SSL certificates are not officially supported by Centova but it worked in our case (solely dealing with the Centova front end).

Centova Cast uses Nginx style certificates. Here is our SSL provider (Comodo) instructions on how to create these:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/1091/0/certificate-installation--nginx

If anything untoward happens during the SSL cert installation you can revert to a self-signed certificate by typing "/usr/local/centovacast/sbin/setssl self example.com", via your SSH console, where example.com is your actual domain name.

I hope this is helpful.
-_R