It would help if you provided the port and domain name for the server that is failing. Also, is that alternate port 8XXX served by your nginx or is nginx just a proxy to something else that serves your audio stream?
Note the renew command in your post worked but did not update your certificate. There was no reason to as it does not expire for 58 more days. That is why the message said "skipped" - there was nothing necessary to do.
Without more info it is hard to advise. You can check your own certs with a site like the one below. Enter the domain name and port to see your certs. Maybe that will be enough for you to see and fix your problem. https://decoder.link/sslchecker
Note that site shows your 443 server certificates for reggaespace.com as being just fine.
This would be used to listen to our audio stream. It worked up until the certificate for reggaespace.com renewed two days ago. This is preferred as it avoids ‘mixed content’ issues on the player page (https://www.reggaespace.com/wrs-audio/).
Hmm. Yes, I see now the cert that is sent from your 8012 server expired 3 days ago.
It looks like nginx is using a different certificate file for the server with "listen 8012;" compared to the one with "listen 443;". If you want us to look at it please post the results of this command: sudo nginx -T (omit sudo if you are already root, capital T is important)
When you paste the results please use the preformatted text option in the menu (Ctrl-E).
An important thing to note is your cert history shown here. You have issued various combinations of cert names - some with just reggaespace.com and others with www, stream, and so on.
Your port 443 server is using the one issued on Oct17 but your 8012 server looks like it is using one of them issued on Aug18. Maybe this is enough for you to see what is going wrong. If not, please post the nginx -T as I described.
Yeah, agreed. I was relying on their comment that nginx was serving audio but you and Osiris are right that is not the case.
@Tuzongo I am not familiar with Icecast but you need to review its configuration and make sure it refers to the current certificates. That is, that it uses the same ones that nginx is using for your 443 servers. The Icecast docs say it needs a "bundle" containing the privkey.pem along with the fullchain.pem so you must have manually created that at one point (or maybe as a deploy hook?). You need to repeat what you did for that. See: https://icecast.org/docs/icecast-2.4.1/config-file.html
Search that page for ssl-certificate for the config location and the description of the bundle
If this is the actual correct place for IceCast to configure TLS certificates, this path is not automatically updated by certbot. You probably copied the certificate from /etc/letsencrypt/ to that /etc/icecast2/ location. If possible, use the path in /etc/letsencrypt/live/${name_of_certificate}/fullchain.pem directly(Edit: as @MikeMcQ already pointed out and what I missed is that it requires the certificate bundle and private key) and if that's not possible (e.g. due to permission issues), make a script which takes care of all the copying, chown-ing and reloading IceCast stuff and configure that script as a --deploy-hook in certbot.
<!-- The certificate file needs to contain both public and private part.
Both should be PEM encoded.
-->
<ssl-certificate>/etc/icecast2/bundle.pem</ssl-certificate>
You must have followed a guide/instructions that had you combine the (fullchain) cert and key files into this file: /etc/icecast2/bundle.pem
You will have to update that bundle file and also systemctl restart icecast2 each time a new cert is issued (there is --deploy-hook option in certbot to help with this step).