Yes, but does icecast know to look for it there?
yes it it's on my xml file it 's just when i past it here it re move < >
ok, to avoid that you can use ` backticks
`<xml>` becomes <xml>
That says it is 5560 bytes. My fullchain files (long chain) are about 5600 bytes. My privkey files are about 1700 for a total close to 7300. Are you sure you have combined the fullchain and privkey pem files to make the bundle.pem?
ls -l /opt/bitnami/letsencrypt/certificates/
total 20
-rw------- 1 bitnami root 5333 Mar 15 22:42 hooggar.com.crt
-rw------- 1 bitnami root 3751 Mar 15 22:42 hooggar.com.issuer.crt
-rw------- 1 bitnami root 232 Mar 15 22:42 hooggar.com.json
-rw------- 1 bitnami root 227 Mar 15 22:42 hooggar.com.key
this my cat command i take the .crt and the .key file
cat /opt/bitnami/letsencrypt/certificates/hooggar.com.crt /opt/bitnami/letsencrypt/certificates/hooggar.com.key > /usr/share/icecast2/bundle.pem
How many times does the word "BEGIN" (all caps) appear in that file?
(It should be more than two. Either 3 or 4)
cat /usr/share/icecast2/bundle.pem|grep BEGIN |wc -l
4
based on the command i have 4 on the file i concatenated however in my case i dont have a fullchain file i have only this:
ls -l /opt/bitnami/letsencrypt/certificates/
total 20
-rw------- 1 bitnami root 5333 Mar 15 22:42 hooggar.com.crt
-rw------- 1 bitnami root 3751 Mar 15 22:42 hooggar.com.issuer.crt
-rw------- 1 bitnami root 232 Mar 15 22:42 hooggar.com.json
-rw------- 1 bitnami root 227 Mar 15 22:42 hooggar.com.key
I think your hooggar.com.crt is the fullchain (based on size and # of BEGINs).
But, I think something is wrong with the key. What does this say?
sudo openssl rsa -check -noout -in /opt/bitnami/letsencrypt/certificates/hooggar.com.key
It is normally closer to 1700 bytes.
Do not show us the key file though - private keys must be kept private!
Now I'm curious about mine:
- RSA4096 on R3: 5946
- RSA2048 on R3: 5609
- P-256 on R3: 5329
- P-256 on E1: 3968
(What the... How are they so close? -- they're not, I checked the wrong certificate)
(The keys are another story, ~3200, ~1700 and ~300)
So, it looks like you were concatenating the files correctly.
We don't know why icecast would not support ECDSA given it uses openssl.
I don't have any other ideas. Maybe @9peppe or someone else will think of something more. Best of luck.
What I don't get is why would Icecast just ignore some but not others of those configuration options.
I don't know either. Is there an icecast community somewhere?
Should OP drop plans to use TLS with icecast directly and try again reverse proxying with nginx? I don't know that either.
One prior icecast poster had to drop TLS because some (all?) of the hardware radios that would connect to their icecast server did not support HTTPS.
Yeah, I remember. But serving both http and https should be allowed, I think.
so far i have 2 VM on google cloud and 1 in oracle cloud
the google cloud vm use debian 10 and the bitnami nginx package
the oracle vm is under centos 7 but use httpd apache server
i will install lets incrypte (cerbot) and see if it will fail like on Debian
Wait. If you can install WordPress/bitnami somewhere and icecast somewhere else it's probably better. That way you can just use a different subdomain and hope TLS works this time.
i have the same problem on the second server
http://www.usdzradio.live:8443/mount
the port come up as http not as http
On the second server you can use 80 and 443 
Maybe telling it to use 443 will shame icecast into actually using TLS.