Certbot and Icecast

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.

My domain is: vs39.applesources.net

I ran this command: certbot certonly --webroot-path="/usr/share/icecast2/" -d ‘vs39.applesources.net

It produced this output: Domain: vs39.applesources.net
Type: unauthorized
Detail: Invalid response from
http://vs39.applesources.net/.well-known/acme-challenge/H9Cw5szzfD8TG69MkzsPLe4ENl89PEQEGWpGo4dylyk
[209.141.61.140]: 404

My web server is (include version): icecast 2.4.4

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?

Tony

1 Like

Welcome to the Let’s Encrypt Community :slightly_smiling_face:

Credit goes to @Osiris for diligently finding the webroot for icecast.

Perhaps try this:
certbot certonly --webroot -w /usr/share/icecast2/web/ -d vs39.applesources.net --dry-run

If it works, remove --dry-run and run it again.

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.

Once your (real) certificate is actually issued (after removing --dry-run), you will be able to see it here:

https://crt.sh/?q=vs39.applesources.net

Also, your version of certbot is ancient:
0.40.0 vs 1.8.0

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? :wink:

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 :slight_smile:

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 :slight_smile:

1 Like

@Osiris

Hello? :slightly_smiling_face:

Port 80 works fine. The OP said so, twice, and I verified it.

You’re tripping up a bit today Osiris. Good job with the icecast webroot though. That part I couldn’t verify. :slightly_smiling_face:

1 Like

Thanks for all your help.

I now have this server working.

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.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.