Looks like the cert expired on Christmas Eve? Anyone experiencing any issues connecting to the conventional feed CDN?
*.broadcastify.com ssl cert expiration?
- Thread starter mikewren
- Start date
What is the "conventional feed CDN?"
Works fine for me on numerous computers over numerous networks, however on my phone it gave me the same error, cleared my cache and worked fine, haven't had an issue since
I still don't understand why your phone etc is connecting to audio3 to listen?
Thanks for fixing.
Can you advise why you are using audio3 for listening purposes? I need to understand the use case here before I start blocking listeners at the master servers
I'm not listening via audio3.
I have a SSL cert check set up on my end as an ounce of proactive prevention, as there's a precedent of Broadcastify allowing certs to expire. This causes upstream issues with feed providers (like myself) using trunk-recorder. The last time it occurred in 2022 I lost a couple hours due to troubleshooting why my server load was suddenly so high as to cause audio issues. The "fix" was to disable all Broadcastify uploads until the cert was updated.
Last edited:
Why did you choose audio3 as your “certificate check” host instead the Broadcastify calls api host?
The audio3 server is completely decoupled from anything calls related, and actually runs a different ssl certificate, expiration, and CA than the calls API infrastructure. It is an icecast master server, and really doesn’t have a need to support SSL since it doesn’t support listener clients.
Since that episode back in 2022 the calls api infrastructure automatically renews SSL certificates seamlessly.
The audio3 server is completely decoupled from anything calls related, and actually runs a different ssl certificate, expiration, and CA than the calls API infrastructure. It is an icecast master server, and really doesn’t have a need to support SSL since it doesn’t support listener clients.
Since that episode back in 2022 the calls api infrastructure automatically renews SSL certificates seamlessly.
The two conventional feeds I provide were assigned to audio3 and audio9 - these, along with calls host are all checked on my end proactively since I've been burned before - this is my first quick troubleshooting step if/when something breaks. Will pull cert checks on the icecast CDN's as they're http traffic, thanks!
I don’t understand quite what this means. Can you elaborate further?
will pull = will remove/omit audio3 and audio9 from my further cert checks as their cert expiration is a non issue in practice. Cert validation (and latency monitoring) is something that already runs to proactively keep tabs on other sites and services I maintain.
CDN = content distribution network; It's a more generic industry term for the function of the icecast servers.
CDN = content distribution network; It's a more generic industry term for the function of the icecast servers.
Last edited:
