Starting with What Made Sense
So the Krypton Radio web site has to go full SSL now because most modern web browsers (read “Google Chrome”) won’t let people visit without warning them that your web site will slay your children in their sleep if you don’t have an SSL certificate on it.
This is frankly just Google messing with our heads, for the most part. A site that does not handle money shouldn’t have to worry about this. All the monetary things we need to do are handled by external sites that actually are secure. But I digress.
So our first assumption was that we could just buy a cert from secureserver.net, install it on Centova, Icecast and our main web server and we were probably good to go.
And then everything collapsed.
What We Did First
I went to create our private key and Certificate Signing Request. After a few tries, I finally was able to use CPanel to generate this, adding in wildcard domains for every domain we wanted to cover. This is a completely legal thing, and you can buy one certificate to handle as many domains as you want.
If you actually buy it through CPanel, though, you can’t. It’s one domain per cert, and $30 per cert. Buying it through your registrar, though, is a lot cheaper. If you own ten domains, you can easily spend a bundle doing this, and there’s literally no reason for it. Shall we spend 10% of the cost Cpanel wants us to spend?
Yes. Yes we shall.
Mind you, the only reason we’re doing that is that when we started all this there was no such things as Let’s Encrypt, which is a free secure certificate signing company.
The only catch to certificates you get from Let’s Encrypt is that the certificates expire after 90 days, so it’s kind of a problem if you want to use them with a mail server. Every three months your users will have to accept a new SSL certificate to get their email, and trust me, it wigs them out. Most people can barely operate the send button.
That Utterly Failed
No matter what we did with the certificates supplied to us by secureserver.net, Centovacast hated them. The installation script provided by Centova (your installation will tell you that the script lives at /usr/local/centovacast/sbin/setssl) just barfs on it every time.
The instructions provided by Centova say to get Apache credentials. This is wrong. You need credentials for something, but whatever it is, it wants a .pem file, and whatever is supposed to be IN that .pem file isn’t documented.
If you can get a .pem file, great – otherwise, you’ll have to do a massive workaround.
The Icecast Connection
So that’s when we figured out that Icecast, the Centova main panel , and WordPress all needed to be set up with certificates, and that not all of them were going to be able to use the same ones.
Here’s the instructions I found on how to do that for Icecast.
Note with particular attention that they’re talking about putting the private key, the public key, and the authority chain all in one file. I found a BBS topic on how this should be done, specifically with Let’s Encrypt.
The authority chain from LetsEncrypt comes in in the chain.pem file as created by the Centova LetsEncrypt utility, and that’s stored in /usr/local/centovacast/etc/ssl/certs, and then from there there are directories corresponding to each domain. The fact that they bother to identify files by domain name teases the fact that may be possible to run Centovacast from more than one valid domain so long as the server answers to multiple domains.
To inspect the certificates being managed by CPanel, you need to log into your WHM panel and go to:
Home » SSL/TLS » SSL Storage Manager
The Centovacast Connection
I never got the certs I bought working with Centovacast, and self-signing isn’t an option, so I went ahead and asked the Centova Utility at /usr/local/centovacast/sbin/setssl to create the certs for me using Let’s Encrypt.
To do that, you need to set up a directory alias on a web server on the same domain as Centovacast to serve up the validation files Let’s Encrypt needs to prove that you’re who you say you are.
The instructions say to use a specific block of code to define the directory alias that points to where those validation files are held on the server, but it says nothing about where in your Apache file to put them.
You’re going to need to set up your aliased directory so that the same domain that handles your Centova server is being served as a regular domain or subdomain on port 80, which is the standard port for serving web pages.
In my case, I had a subdirectory called ‘station’. I had to create a server alias so that that subdomain was included in the list of other servers my main vhost listing handles for me, so that my Centovacast subdomain and my main one are really being handled by the same vhost. This saved me from having to set up a complete separate vhost just to handle this one fricking problem.
It also gives the incorrect code to insert in the first place. Forget what they say in their article. Here’s the correct code:
Alias /.well-known/acme-challenge /usr/local/centovacast/etc/ssl/acme-challenges
Allow from all
Require all granted
# Apache 2.x
Allow from all
# Apache 2.4
Require all granted
Big question: Regarding the ‘setssl’ utility, why put broken code in a utility, and then write documentation that pretends it works? Again?
Centova is notorious for this.
When we fixed all of the above basic configuration with the Apache server to satisfy the needs of LetsEncrypt, we found that the setssl script was changing permissions on the target file folder such that it would return a 403 error.
That’s right, the Centova utility script that installs the certificate intentionally breaks the process so that it can’t finish.
Insert the change in the chmod instruction that alters it from 750 to 755.
For some reason this bug has been in there forever, and Centova’s never fixed it. They say the answer to this problem is to make the user that the Apache server runs under a member of the ‘centovacast’ group, but in my experience this didn’t work and I got a 403 error no matter what I did later.
Anyway, here’s the code to modify:
if [ ! -e “$challengepath” ]; then
mkdir -p “$challengepath”
chown root.centovacast “$challengepath”
chmod 0755 “$challengepath”
echo “$testcontent” > “$challengepath/$testfilename”
#(In later versions of the code, these two lines are missing entirely. If they’re present, make the change to the chmod parameter as shown).chown root.centovacast “$challengepath/$testfilename”
chmod 0755 “$challengepath/$testfilename”
Once I patched my copy, I set the file permissions on it so that future Centova updates couldn’t revert my changes, like they did the last three times.
You’re Not Out of the Woods Yet
It’s not enough to get Centova itself running on an SSL certificate. Now you have to get IceCast itself working with SSL, which for some reason is a separate task, and any attempt to link to an unsecured stream from a secured site will make web browsers claim your site is not secure, thereby defeating the whole point of having a certificate in the first place.
So the trick here is, you will probably have to create a new listen socket beyond your default. Centova, by default, set you up on port 8000. I had to create a new secure port, so I moved it well up out of the way, on port 8080. All the mount points are available on both ports, but you can’t have one port be both secured and unsecured.
Your Icecast config isn’t called icecast.xml in a Centova installation. It’s called server.conf, and it’s also in a nonstandard location, which is /usr/local/var/vhosts/<your station name>/etc/server.conf.
Here are the listen socket sections from my server.conf. It’s the top one you’re looking at. The bottom one is the default definition, and the top one is the secure one. Centova does not support the direct creation of secure listen sockets, so you have to hack this by hand.
Then finally, you’ll have to add a line in your server.conf file that loads the required SSL certificate. If you’re running your Icecast stream and your Centova server from the same domain, you can reuse the same bundle.pem file, but there’s literally nothing stopping you from making a separate one for each individual Centova virtual host and putting each bundle.pem file in a separate place.
The line for your server.conf file looks like this:
Once this is done, you can go to the Centova interface and reload the server, and it will inhale the new settings. You can test them to make sure it worked by going to https://<yourdomain>:8080 and seeing if it loads. If it doesn’t, you’re still broken, but if it does, congratulations, you now have a secure stream on your internet radio station’s business end!
Except that that doesn’t quite do it.
So it’s /usr/local/letsencrypt/letsencrypt-auto renew,
then rebuild your Icecast PEM file, then use your modified setssl script:
/usr/local/centovacast/sbin/setssl letsencrypt <your domain name>
and then after all that, you have to both restart centova, and then stop your Icecast instance completely and restart it before Icecast will use the new certificate.
Now you’re done.
What a fricking ordeal.