Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
The operating system my web server runs on is (include version): Ubuntu Linux 20.04.1
My hosting provider, if applicable, is: ME
I can login to a root shell on my machine (yes or no, or I don’t know): YES
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): webmin
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.40.0
I have Icecast running on port 80
Do I have to install something to get /.well-known/acme-challenge/H9Cw5szzfD8TG69MkzsPLe4ENl89PEQEGWpGo4dylyk to be created? I have pem files under /ect/letsencrypt
The remarks unauthorised is strange. The DNS works and is an A record. You can see IceCast page at vs39.applesources.net:8000 and port 80
Where should the webroot be for icecast?
If you check your output further, you will probably see something like "Authenticator: None" since you specified a webroot path (--webroot-path or -w), but did not actually specify to use the webroot authenticator (--webroot or -a webroot).
Please heed this though:
Note that to use the webroot plugin, your server must be configured to serve files from hidden directories. If /.well-known is treated specially by your webserver configuration, you might need to modify the configuration to ensure that files inside /.well-known/acme-challenge are served by the webserver.
I don't know if Icecast has a webroot at all. Webroot is the directory where a file serving webserver puts their files. But not every webserver also serves files just from a directory. It could be Icecast only has a webserver for their internally configured sources. Found it:
The file /etc/icecast.xml has the following section (I'm just pasting the start here):
<fileserve>1</fileserve>
<paths>
<!-- basedir is only used if chroot is enabled -->
<basedir>/usr/share/icecast</basedir>
<!-- Note that if <chroot> is turned on below, these paths must both
be relative to the new root, not the original root -->
<logdir>/var/lib/log/icecast</logdir>
<webroot>/usr/share/icecast/web</webroot>
<adminroot>/usr/share/icecast/admin</adminroot>
(...)
See anything familiar?
I just tested it on my freshly installed Icecast:
erazer ~ # cd /usr/share/icecast/web
erazer web # echo 1234 > test
erazer web # curl -Lv http://localhost:8000/test
* Trying ::1:8000...
* connect to ::1 port 8000 failed: Connection refused
* Trying 127.0.0.1:8000...
* Connected to localhost (127.0.0.1) port 8000 (#0)
> GET /test HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/7.72.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: Icecast 2.4.4
< Connection: Close
< Date: Sun, 13 Sep 2020 17:39:48 GMT
< Content-Type: application/octet-stream
< Cache-Control: no-cache, no-store
< Expires: Mon, 26 Jul 1997 05:00:00 GMT
< Pragma: no-cache
< Accept-Ranges: bytes
< Content-Length: 5
<
1234
* Closing connection 0
erazer web #
So there you have it
Of course you'll need to use port 80 (and not port 8000), as that's mandatory for the Let's Encrypt challenge.
Without changing anything else, --dry-run won't magically fix anything.
As far as I know, there aren't any major bugs in 0.40.0
Yes indeed the webroot has to be /usr/share/icecast2/web as that is where the icecast miniserver looks for data. I have the cert installed and am now working on getting another server working. This was the test bed for a clients service.
