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
<Directory “/usr/local/centovacast/etc/ssl/acme-challenges”>
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
Require all granted
# Apache 2.x
<IfModule !mod_authz_core.c>
Order allow,deny
Allow from all
</IfModule>
# Apache 2.4
<IfModule mod_authz_core.c>
Order allow,deny
Require all granted
</IfModule>
</Directory>
Recent Comments