So it did require a2ensite.
I wonder why you didn’t try that sooner…
1 Like
@rg305 Because the original domain had worked until I messed with the subdomain on Box 2. I didn’t suspect that (re-)enabling it would be needed, but it was logical that the subdomain would have to be enabled. I found out when I mulled over the result from apache2ctl -S.
1 Like
it’s because you had multiple virtualhosts on port 443 with different ssl activation statuses: SSLEngine on was missing in the one that prevailed.
1 Like
So then… (file) “Order Matters”.
[I often tell my kids this - like: “Socks go in before shoes (not after)!”]
Or an even better takeaway: SSLEngine on should probably be initiated in the main config.
And, of course there is also, placing a file in the sites-available folder usually does nearly nothing - without also enabling it (via: a2ensite <site>)
1 Like
No, because you don't want to break port 80.
I don't know how apache solves this kind of conflicts -- is it the first? is there a default? -- but it's safe to say that it should be in every port 443 vhost (or in none, but that doesn't make sense)
1 Like
OK so then:
Apply SSLEngine on within ALL TLS sections.
[that seems to work in my test Apache system]
2 Likes
yes, and that’s not a problem if you use certbot.
because you can create a section on port 80 only, with no SSLEngine directive and so, and certbot will create a new TLS section with the right configs.
2 Likes
Well, we are beyond the SSL problems, and your help has solved the most serious problems, but I am not totally where I want to be. I cannot ask you to help me, as we are outside the scope of this forum. However, I would be grateful for any hints as to why my little internet radio doesn’t work. Thank you.
1 Like
because the url it’s configured to load is
http://192.168.88.44/radio/8000/radio.mp3?1584820922
instead of the proper public one.
There should be configuration options in your application.
3 Likes
To add some clarity to this…
The initial URL seems useable: https://hjarteleg.velko.men/public/radio
Where
Name: velko.men
Address: 79.170.87.117
Aliases: hjarteleg.velko.men
But the redirection to, or use of, an RFC 1918 IP address (192.168.88.44) makes it unreachable.
I do see that now the site is returning 503 Service Unavailable; perhaps that means you are making changes and hopefully making progress.
Best of luck 
Edit: now I see this again: https://192.168.88.44/public/radio
curl -Iki https://hjarteleg.velko.men/public/radio
HTTP/2 307
date: Sat, 21 Mar 2020 21:57:52 GMT
server: nginx
strict-transport-security: max-age=15768000; includeSubDomains; preload
content-type: text/html; charset=UTF-8
location: https://192.168.88.44/public/radio
x-xss-protection: 1
x-content-type-options: nosniff
x-robots-tag: none
referrer-policy: no-referrer-when-downgrade
1 Like
The problem is within the nginx configuration.
It seems to be redirecting (307 temporary) instead of proxying.
I assume the 307 is returned by the app, not by nginx.
This was indeed an issue with the app. It has a “prefer browser URL” checkbox that has to be disabled. The radio station should now basically work. The intent is to broadcast my own concerts and readings for people who are house-bound and quarantined.
2 Likes
I can hear it fine. It works. 
There's a little problem, the actual mp3 file is served over unencrypted http, you get a mixed content 
warning. You should tell the app to use browser protocol/schema too (or to use relative urls)
2 Likes
Thanks The mixed content warning is not unusual with Icecast streams, because it doesn’t have support for SSL due to licensing issues (sic) unless you build it from source yourself. That’s why, I am told. This is not ideal for modern browsers, AFAIK Chrome doesn’t allow it at all.
2 Likes
This is why you should get apache on box1 to handle this.
what’s its virtualhost config for the webradio right now? (it’s redirecting, that’s good)
1 Like
Hi @eivind
these
http://hjarteleg.velko.men/static/img/generic_song.jpg
http://hjarteleg.velko.men/radio/8000/radio.mp3?1584878447
are your addresses, that's your mixed content.
1 Like
I looked around, the setting you should be looking for is “use web proxy” or something like that: https://www.azuracast.com/extending/cloudflare.html#enabling-cloudflare-with-azuracast
(and check the mount point url)
1 Like
There is a web proxy setting, and it is already switched on. The documentation says that this routes all radio through ports 80 and 443 instead of the standard Icecast port 8000.
1 Like
we need to make azuracast believe it’s https even if it’s serving unencrypted http.
you can try adding to the apache proxy config something like:
RequestHeader set X-Forwarded-Proto %{REQUEST_SCHEME}
and hope it works.
1 Like