From phschafft at de.loewenfelsen.net  Mon Jul 10 09:31:06 2017
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Mon, 10 Jul 2017 09:31:06 +0000
Subject: [Icecast] SSL Setup
In-Reply-To: <ojul1i$lu4$1@blaine.gmane.org>
References: <ojul1i$lu4$1@blaine.gmane.org>
Message-ID: <1499679066.1841.6.camel@de.loewenfelsen.net>

Good morning,


On Mon, 2017-07-10 at 01:25 +0000, ScanCaster wrote:
> IceCast is one of the last services I have that doesn't connect securely, 
> and I am looking to close that hole....
> [...]

> OK... add a port for SSL for IceCast in icecast.xml...path for cert file 
> in same.... no biggie

The <ssl-certificate> belongs in the <paths> section of the config file.
(I'm not sure what you mean with 'in same', just wanted to make it
clear.)


> The key/cert needs to be in a dir and file with applicable permissions 
> for the IceCast user... no biggie..
> 
> chown icecastusergroup:icecastusergroup  certfile


> What I am looking to confirm is that the cert file needs to contain:
> 
> -----BEGIN RSA PRIVATE KEY-----
> MII
> -----END RSA PRIVATE KEY-----
> 
> -----BEGIN CERTIFICATE-----
> MI
> -----END CERTIFICATE----- 
> 
> Where the Cert is the file/text Comodo sends me, and the key is the one 
> openssl spit out earlier, 
> 
> Combine them up in certfile, Correct? Special order?? KEY then Cert, or v-
> v? Line separating them?

The format is the OpenSSL format: key, blank line, cert (chain).
echo | cat key.pem - cert.pem > combo.pem


> kill -HUP pidOfIcecast

As of Icecast2 2.4.x you need to restart Icecast to reload the cert.
There is however a fix in 2.5.x (development) which is hopefully
released with the next development update.


> And good????
> 
> One thing can the web server spit out just a text file that is used by 
> Comodo to verify ownership of the domain? The DNS method normally 
> fails....

Sure. Just put it into the webroot (<webroot> in <paths>). Icecast
handles files in webroot according to your operating system's mine-type
table.


> ie: http://icecast.domain.invalid/somestringofletersnumbers.txt That they 
> request if its dumped in the webroot stuff of Icecast? With out any XSLT 
> markup?

Icecast only processes XSLT files as XSLT.


> So if I added a listening port on 80 for this, then took it away, 
> since I don't use that for Icecast... Icecast is on its own server which 
> does not have Apache... web stuff for other things is on its own box. I 
> never have used the Icecast to server up anything other than the default 
> admin etc. stuff it does by default...

To avoid the need to run Icecast as privileged user in oder to bind to
low ports (if Comodo really insists in using port 80) you can use your
firewall to do a local redirect.


Hope this is of help to you,

with best regards,


-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon: +49.3535 490 17 92

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170710/3dc6b4c6/attachment.sig>

From walteryork at hotmail.com  Mon Jul 10 15:33:08 2017
From: walteryork at hotmail.com (Walter York)
Date: Mon, 10 Jul 2017 15:33:08 +0000
Subject: [Icecast] SSL Setup
In-Reply-To: <ok0021$h3s$1@blaine.gmane.org>
References: <ojul1i$lu4$1@blaine.gmane.org>
 <1499679066.1841.6.camel@de.loewenfelsen.net> <ok0021$h3s$1@blaine.gmane.org>
Message-ID: <BN6PR16MB0018E0E63475DB70459E57B5D9A90@BN6PR16MB0018.namprd16.prod.outlook.com>

I use Let's Encrypt for SSL with icecast.  Here is my rudimentary script on GitHub... It does NOT require Apache or nginx.

https://github.com/amavarick/letsencrypt_certbot_standalone_icecast

On Jul 10, 2017, at 9:39 AM, ScanCaster <scancaster at scancaster.net<mailto:scancaster at scancaster.net>> wrote:

On Mon, 10 Jul 2017 09:31:06 +0000, Philipp Schafft wrote:

 Good morning,
 The <ssl-certificate> belongs in the <paths> section of the config file.
 (I'm not sure what you mean with 'in same', just wanted to make it
 clear.)


"in same" = in same file, icecast.xml


 The format is the OpenSSL format: key, blank line, cert (chain). echo |
 cat key.pem - cert.pem > combo.pem

Thats what I needed to verify...

 kill -HUP pidOfIcecast

 As of Icecast2 2.4.x you need to restart Icecast to reload the cert.
 There is however a fix in 2.5.x (development) which is hopefully
 released with the next development update.

Unfortunately, for our setup, a change for "security" reasons affects our
operations, in that metadata is not accepted from an IP which is not the
sources IP. We have server wide metadata that is written to our sources
at times. So we have to stick to a version prior to this, 2.4.2 or so or
all our scripts break. If there is an option to allow an override of
this, we would look to update, but if not, the server wide metadata is
more important.

 Sure. Just put it into the webroot (<webroot> in <paths>). Icecast
 handles files in webroot according to your operating system's mine-type
 table.

Yeah, I dumped an old test file in there from an old domain, and tried
it, worked, fine... a little redir 80 to 8000 and that will suffice.

 Icecast only processes XSLT files as XSLT.

Just like to verify, since I never touched any thing in that server.


 To avoid the need to run Icecast as privileged user in oder to bind to
 low ports (if Comodo really insists in using port 80) you can use your
 firewall to do a local redirect.

  We can  do a redir via some software, but yes, Comodo insists that is
either on 80 or 443 if you do their web based verification. The DNS one
on 53, I've never ever got to work. I personally think they are too quick
to look and then give up on looking at the DNS server for their TXT
record and/or don't pull it direct from the DNS server with authority
which would show the change immediately. Don't know, except that its been
100% failure when trying to use it.

Thanks.

________________________________

Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170710/1794e989/attachment.htm>

From walteryork at hotmail.com  Mon Jul 10 17:21:15 2017
From: walteryork at hotmail.com (Walter York)
Date: Mon, 10 Jul 2017 17:21:15 +0000
Subject: [Icecast] SSL Setup
In-Reply-To: <ok07fr$h3s$2@blaine.gmane.org>
References: <ojul1i$lu4$1@blaine.gmane.org>
 <1499679066.1841.6.camel@de.loewenfelsen.net> <ok0021$h3s$1@blaine.gmane.org>
 <BN6PR16MB0018E0E63475DB70459E57B5D9A90@BN6PR16MB0018.namprd16.prod.outlook.com>
 <ok07fr$h3s$2@blaine.gmane.org>
Message-ID: <BN6PR16MB00185C7E826EE00A8BB442BAD9A90@BN6PR16MB0018.namprd16.prod.outlook.com>

That's why I setup a chron job to run once a month.  The script will update the cert, concatenate the cert and stop and start the services.

On Jul 10, 2017, at 11:46 AM, ScanCaster <scancaster at scancaster.net<mailto:scancaster at scancaster.net>> wrote:

On Mon, 10 Jul 2017 15:33:08 +0000, Walter York wrote:

 I use Let's Encrypt for SSL with icecast.  Here is my rudimentary script
 on GitHub... It does NOT require Apache or nginx.

Thanks, but Lets Encrypt is out due to the 90 day length of certs.

Install once/update once per year, fine, but not every 90 days. Nope.

Thanks for the info though.


________________________________

Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170710/eaf153fb/attachment.htm>

From lion at lion.leolix.org  Fri Jul 14 09:16:34 2017
From: lion at lion.leolix.org (Philipp Schafft)
Date: Fri, 14 Jul 2017 09:16:34 +0000
Subject: [Icecast] Source Drops, metadata, and source limits in setup
In-Reply-To: <ok9ebj$of8$1@blaine.gmane.org>
References: <ok9ebj$of8$1@blaine.gmane.org>
Message-ID: <1500023794.14056.60.camel@lion.leolix.org>

Good morning,


On Fri, 2017-07-14 at 03:38 +0000, ScanCaster wrote:
> An issue I've been trying to track down for quite a while is
> 
> Source Drops... 
> 
> especially say 4 sources from the same IP, dropping all at once. 
> 
> Or ALL sources on the server just dropping ALL AT ONCE. Sources in this 
> case are from differing locations and differing ISP's.
> 
> Yes, internet has its spordaic issues, not the cause....
> 
> Why do I say that?
> 
> Well after a hunch I took my icecast.xml and just upped the sources and 
> client counts to some HUGE RIDICULOUS NUMBER.
> 
> And POOF! That seems to have made the issue disappear!Although I am 
> wondering if this is going to cause a core dump or something if these are 
> hogging RAM etc...

You can easily check the RAM used by Icecast2 using e.g. top(1). Most
relevant is 'RES' which is the amount of in-core memory. However there
is no memory related problem known to me on any of the stable official
Icecast2 releases.


> What I am wondering is if the cause of this is metadata updates! Why? For 
> my case metadata updates can come in fast and furious every 5-10-20 
> seconds or so... versus say 3-10 minutes for something spitting out music 
> or something... I am not doing music..

This posting confirms me in that I should write a separate e-mail to the
list on how metadata updates work and how they should be implemented on
the source side.


> I am wondering if there is something where the metadata updates are 
> CLOGGING UP the source connections and thus once full, even though the 
> clients have been connected for days, they now drop.

No. Manual updates using the admin web interface is exactly that: admin
interface requests. It's just normal clients.

You can confirm this by having a look at the accumulative counters for
sources and clients. The client counter will increase for every client
while the source counter only for source connections.


> I use BASH scripts with wget to pass the metadata update which gets data 
> from my another data stream:
> 
> wget -q --delete-after --http-user=admin --http-password=Top_SECRET 
> http://audio.domain.invalid:8000/admin/metadata?mount=/MyMount
> \&mode=updinfo\&song=[This+is+who+is+talking]+$RANDOM >/dev/null

Why don't you use -O /dev/null? Also make sure you both quote the song
parameter first to HTTP standards and then to shell standards.

I think the redirect of stdout is mostly useless.
This also will allow each and every process on the same system to spot
the password.


> Is there something where these updates, don't release the connection for 
> a while, and a SETTING TO CHANGE THAT??? source-timeout??? 

No.

The source timeout is only to allow some jitter within the TCP flow
(e.g. to compensate lost packets). The only reason to increase it is a
bad network. And if you're on a bad network you should very likely
rethink your setup.


> Sporadic issues with routers, data traversal on the public internet I 
> get.. When FOUR SOURCES DROP ALL AT THE SAME TIME on an IP where things 
> are running fine for other things...and changing this setting, seems to 
> cure it. Colors me curious... 

Which *exact* version of Icecast2 do you run and where have you got it
from? Which operating system are you using?


Icecast2 will write a message to the error.log in case there is some
problem with a client. What is the relevant section of the error.log?
Also have a look at the access.log. It will list all the clients after
they have disconnected. This includes the source connections as well as
admin interface interaction.

Without input from the log files it's hard to tell. Here are some of my
guesses:
      * Your network has some kind of a problem. Maybe a bad cable right
        on the server? (Would explain why source fail at the same time
        and why altering timeouts may help.)
      * You're running a non-official version of Icecast2. (could
        explain everything or nothing.)
      * One of your scripts do random things. E.g. because of faulty
        escaping. (Could explain random drops.)
      * Your admin and/or source credentials are known to someone else.
        (Could explain all of those things.)
      * You're not running one of the stable and supported versions.
        There could be an attack based on a security problem of an old
        version going on. (Could explain all of those things.)
      * Your machine has some kind of hardware malfunction, e.g. bad
        RAM. (Could explain all of those things.)
      * A still unknown bug in Icecast2. (Could explain all of those
        things.)
      * A mixture of what is above.

The logs will easily tell if there is a timeout related problem, that
always means the network has some problem. It will also tell if there
are related admin interface requests. Both of this considering one of
the stable and supported versions of Icecast2.

With best regards,

-- 
Philipp.
 (Rah of PH2)


From raylutz at cognisys.com  Mon Jul 17 23:39:28 2017
From: raylutz at cognisys.com (Ray Lutz)
Date: Mon, 17 Jul 2017 16:39:28 -0700
Subject: [Icecast] Tunein on Vizio plays only 1 sec, works fine elsewhere...
Message-ID: <a95bf8c4-6c59-a829-a83b-22c86b2c3989@cognisys.com>

Hi!

My icecast stream is at http://airprogressive.org:8000/stream Website is 
http://AirProgressive.org

This works on Tunein on most platforms, including Android and PC, like 
this: https://beta.tunein.com/radio/AirProgressiveorg-s141251/

But on Vizio "Smart" TV app, it only plays about 1 sec, then stops with 
no indicated error.

But icecast still believes the stream is connected until I RETURN to the 
previous screen on the VIZIO TV.

Here is a video of the failure on the Vizio TV. 
https://drive.google.com/file/d/0B7VY4zfV7BdVdDQ3T0VqSWo0TjA/view

I changed icecast parameter "burst" from 64K to 128K with no change in 
the failure.

Vizio has "Radiotime Widget" version 0.44.0.

My stream runs at 32kbps and 22050 hz sample rate, joint stereo.

Anyone else come across this?

--Ray








From phschafft at de.loewenfelsen.net  Tue Jul 18 09:41:08 2017
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Tue, 18 Jul 2017 09:41:08 +0000
Subject: [Icecast] Tunein on Vizio plays only 1 sec,
 works fine elsewhere...
In-Reply-To: <a95bf8c4-6c59-a829-a83b-22c86b2c3989@cognisys.com>
References: <a95bf8c4-6c59-a829-a83b-22c86b2c3989@cognisys.com>
Message-ID: <1500370868.1840.9.camel@de.loewenfelsen.net>

Good morning,

On Mon, 2017-07-17 at 16:39 -0700, Ray Lutz wrote:
> My icecast stream is at http://airprogressive.org:8000/stream Website is 
> http://AirProgressive.org

> But on Vizio "Smart" TV app, it only plays about 1 sec, then stops with 
> no indicated error.

Is that TV trying to access the stream using TLS? If so make sure you
have at least OpenSSL version 1.0.2g installed (older versions have a
bug that causes similar behavior).


> But icecast still believes the stream is connected until I RETURN to the 
> previous screen on the VIZIO TV.

Hm, this more sounds like a bug in their application. Does it stay
connected for more than two queue sizes after it stopped? (queuesize /
bitrate)


> I changed icecast parameter "burst" from 64K to 128K with no change in 
> the failure.

Ok.


> Vizio has "Radiotime Widget" version 0.44.0.
> 
> My stream runs at 32kbps and 22050 hz sample rate, joint stereo.


Little side notes:
      * You're running Icecast2 2.4.0 which is still ok, yet there have
        been some fixes (likely not related to your problem) in
        2.4.2/2.3.4.
      * You have set your <hostname> to an IP. It's called hostname for
        a reason. Please change it to your hostname (wich seems to be
        "airprogressive.org" given your stream URL you gave above).
      * You set the stream URL to "http://69.73.185.67". Beside that
        this does not identify a resource at all (invalid URL) you
        likely want to set this to "http://AirProgressive.org/" (note
        the slash at the end) as that is the website for your stream.


Wish you a nice day,

with best regards,


-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon: +49.3535 490 17 92

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170718/c0252a77/attachment.sig>

From lion at lion.leolix.org  Tue Jul 18 10:22:39 2017
From: lion at lion.leolix.org (Philipp Schafft)
Date: Tue, 18 Jul 2017 10:22:39 +0000
Subject: [Icecast] Source Drops, metadata, and source limits in setup
In-Reply-To: <okdv8v$of8$2@blaine.gmane.org>
References: <ok9ebj$of8$1@blaine.gmane.org>
 <1500023794.14056.60.camel@lion.leolix.org> <okdv8v$of8$2@blaine.gmane.org>
Message-ID: <1500373359.1840.26.camel@lion.leolix.org>

Good morning,


On Sat, 2017-07-15 at 20:51 +0000, ScanCaster wrote:
> On Fri, 14 Jul 2017 09:16:34 +0000, Philipp Schafft wrote:
> 
> > This posting confirms me in that I should write a separate e-mail to the
> > list on how metadata updates work and how they should be implemented on
> > the source side.
> 
> And what is different in the way this is updated???

The difference is that doing it correctly does not break the data stream
and will not cause random failure of whatever component in the line.



> > Why don't you use -O /dev/null?
> 
> -O or > /dev/null does the same thing. Like many things in Linux 40 ways 
> to do it.

You're not using -O - at all. And it does not. --delete-after does
something totally different.


> > Also make sure you both quote the song
> > parameter first to HTTP standards and then to shell standards.
> 
> The BASH script takes in this: "039000DB13BE00DB13BE189F" decodes it and 
> spits out:
> [This+is+who+is+talking] 

I don't see the correlation to what I said.


> > I think the redirect of stdout is mostly useless. This also will allow
> > each and every process on the same system to spot the password.
> 
> Since its my box, or my own little devices on the network, and I am the 
> only one who has access its not an issue.
> 
> Each Source gets a unique password. 

True until it changes. Sounds like very fragile security to me.


> > Which *exact* version of Icecast2 do you run and where have you got it
> > from? Which operating system are you using?
> 
> IceCast V2.4.1 on Ubuntu 14.04 on a VPS with 2GB RAM.

ok.


> > Icecast2 will write a message to the error.log in case there is some
> > problem with a client. What is the relevant section of the error.log?
> > Also have a look at the access.log. It will list all the clients after
> > they have disconnected. This includes the source connections as well as
> > admin interface interaction.
> > 
> > Without input from the log files it's hard to tell. Here are some of my
> > guesses:
> >       * Your network has some kind of a problem. Maybe a bad cable right
> >         on the server? (Would explain why source fail at the same time
> >         and why altering timeouts may help.)
> 
> Nope. Internet at source continues to operate fine. Live data coming on 
> the network to verify it is running.

The logs you provided below strongly indicate a network related problem
OR a broken encoder setup. It could also trying to encode digital
silence with a 21th century codec (Vorbis, Opus, ...).


> >       * You're running a non-official version of Icecast2. (could
> >         explain everything or nothing.)
> 
> Nope, V2.4.1 from Ubuntu 14.04 repo

Ok.


> >       * One of your scripts do random things. E.g. because of faulty
> >         escaping. (Could explain random drops.)
> 
> The metadata is "escaped" for BASH. Its straight plain text.

It needs to be escaped for both HTTP and your shell. Otherwise it could
easily break the HTTP part. e.g. if it contains am ampersand ('&').


> >       * Your admin and/or source credentials are known to someone else.
> >         (Could explain all of those things.)
> 
> Unlikely.
> 
> >       * You're not running one of the stable and supported versions.
> >         There could be an attack based on a security problem of an old
> >         version going on. (Could explain all of those things.)
> 
> V2.4.1 is the version I have to run, as a change in the code for metadata 
> updates checks the source IP.. We have reasons for running metadaa 
> updates on sources which the script on the server will not be from the 
> sources IP.

This is simply not correct.
The limitation only applies for raw requests with source credentials. It
is not true for Admin interface requests (rendered) or requests with
admin credentials. And considering your '--http-user=admin' from the
code you have you're likely using admin credentials. (I don't think you
reconfigured Icecast so the source username is 'admin'.)



> >       * Your machine has some kind of hardware malfunction, e.g. bad
> >         RAM. (Could explain all of those things.)
> 
> I've have similar issues on 3 differing hosts over numerous years. From 2 
> VPS on CentOS to another on Ubuntu... the hosts had other issues not 
> related to why I changed.

Which brings us back to my first point as it would mean hardware or
operating system is likely not the cause.


> >       * A still unknown bug in Icecast2. (Could explain all of those
> >         things.)
> 
> 
> >       * A mixture of what is above.
> > 
> > The logs will easily tell if there is a timeout related problem, that
> > always means the network has some problem. It will also tell if there
> > are related admin interface requests. Both of this considering one of
> > the stable and supported versions of Icecast2.
> 
> 
> This is IceCast V 2.4.1 from the Ubuntu 14.04 on a OVZ VPS with 2GB RAM.
> 
> Please note, changing from 2.4.1 to any other version is NOT POSSIBLE. 
> Unless of course the code change that blocks the IP check on metadata 
> updates has been changed to allow any IP to update it.

See above.


> While that may be a security issue by definition for some...
> In my form of broadcasting the server has several server wide
> metadata updates that are applied server wide or for a number
> feeds based on triggers. 

It is. And it is not a problem for streams doing metadata correctly to
begin with.



> From error.log"
> 
> 2017-07-15  15:43:04] WARN source/get_next_buffer Disconnecting source 
> due to socket timeout

'socket timeout' clearly means, that Icecast2 is unable to read data
from the source client for whatever reason (network failure or the
source client not sending data for whatever reasons).


> [2017-07-15  15:43:04] INFO source/source_shutdown Source from 
> 255.255.255.255 at "/mount" exiting

> That line repeats...for each as it happens.. This is the first time in 4 
> days.

yes.


> Sporadic internet blips, happen. They can't all happen at the same time.

Sure they can. e.g. if it's close by. A common example of this a network
cable not correctly plugged into the server. Have seen errors like that
many times. There is a reason why the first question of the helpdesk
always is 'make sure all cables are plugged in correctly'.


> Then the source from location 50 miles away AND different ISP, same 
> things.
> 
> The source(s) reconnect:
> 
> [2017-07-15  15:43:45] INFO connection/_handle_source_request Source 
> logging in at mountpoint "/mount" from 255.255.255.255
> [2017-07-15  15:43:45] WARN format/format_get_type Unsupported or legacy 
> stream type: "audio/mpeg". Falling back to generic minimal handler for 
> best effort.
> 
> Sources are provided by Linux boxes using DarkIce, except the ONE foreign 
> IP one, which has some winslopper application, which is being replaced 
> with one of my dedicated broadcasting boxes on Linux the first week of 
> August. 
> 
> access.log just shows the DarkIce client/sources reconnecting.
> 
>   [15/Jul/2017:15:43:52 -0400] "SOURCE /PL HTTP/1.0" 200 19 "-" 
> "DarkIce/0.20.1 (http://darkice.tyrell.hu/)" 317316
>  [15/Jul/2017:15:43:53 -0400] "GET /admin/metadata HTTP/1.0" 401 331 "-" 
> "Wget/1.12 (linux-gnu)" 0
>  [15/Jul/2017:15:43:53 -0400] "GET /admin/metadata HTTP/1.0" 400 342 "-" 
> "Wget/1.12 (linux-gnu)" 0
>  [15/Jul/2017:15:43:56 -0400] "SOURCE /H.ogg HTTP/1.0" 200 19 "-" 
> "DarkIce/0.20.1 (http://darkice.tyrell.hu/)" 317307
>  [15/Jul/2017:15:44:03 -0400] "SOURCE /Po.ogg HTTP/1.0" 200 19 "-" 
> "DarkIce/0.20.1 (http://darkice.tyrell.hu/)" 263472
> - [15/Jul/2017:15:44:04 -0400] "SOURCE /P HTTP/1.0" 200 19 "-" 
> "DarkIce/1.0 (http://code.google.com/p/darkice/)" 19
>  - - [15/Jul/2017:15:44:05 -0400] "GET /admin/metadata HTTP/1.0" 401 331 
> "-" "Wget/1.12 (linux-gnu)" 0
> 1 - - [15/Jul/2017:15:44:06 -0400] "GET /ma HTTP/1.1" 200 346235 "-" 
> "Softwaree/5" 72
> - - [15/Jul/2017:15:44:08 -0400] "SOURCE /PlaD HTTP/1.0" 200 19 "-" 
> "DarkIce/1.0 (http://code.google.com/p/darkice/)" 0


With best regards,


-- 
Philipp.
 (Rah of PH2)


From artuch at speedy.com.ar  Fri Jul 21 16:41:30 2017
From: artuch at speedy.com.ar (=?ISO-8859-1?Q?Jos=E9?= Luis Artuch)
Date: Fri, 21 Jul 2017 13:41:30 -0300
Subject: [Icecast] SSL Setup
In-Reply-To: <1499685764.1836.3.camel@de.loewenfelsen.net>
References: <ojul1i$lu4$1@blaine.gmane.org>
 <1499685764.1836.3.camel@de.loewenfelsen.net>
Message-ID: <1500655290.1748.5.camel@speedy.com.ar>

Hello !

El lun, 10-07-2017 a las 09:31 +0000, Philipp Schafft escribi?:
> Good morning,
> 
> 
> On Mon, 2017-07-10 at 01:25 +0000, ScanCaster wrote:
> > IceCast is one of the last services I have that doesn't connect
> > securely,?
> > and I am looking to close that hole....
> > [...]
> > OK... add a port for SSL for IceCast in icecast.xml...path for cert
> > file?
> > in same.... no biggie
> 
> The <ssl-certificate> belongs in the <paths> section of the config
> file.
> (I'm not sure what you mean with 'in same', just wanted to make it
> clear.)
> 
> 
> > The key/cert needs to be in a dir and file with applicable
> > permissions?
> > for the IceCast user... no biggie..
> > 
> > chown icecastusergroup:icecastusergroup??certfile
> 
> 
> > What I am looking to confirm is that the cert file needs to
> > contain:
> > 
> > -----BEGIN RSA PRIVATE KEY-----
> > MII
> > -----END RSA PRIVATE KEY-----
> > 
> > -----BEGIN CERTIFICATE-----
> > MI
> > -----END CERTIFICATE-----?
> > 
> > Where the Cert is the file/text Comodo sends me, and the key is the
> > one?
> > openssl spit out earlier,?
> > 
> > Combine them up in certfile, Correct? Special order?? KEY then
> > Cert, or v-
> > v? Line separating them?
> 
> The format is the OpenSSL format: key, blank line, cert (chain).
> echo | cat key.pem - cert.pem > combo.pem
> 
> 
> > kill -HUP pidOfIcecast
> 
> As of Icecast2 2.4.x you need to restart Icecast to reload the cert.
> There is however a fix in 2.5.x (development) which is hopefully
> released with the next development update.
> 
> 
> > And good????
> > 
> > One thing can the web server spit out just a text file that is used
> > by?
> > Comodo to verify ownership of the domain? The DNS method normally?
> > fails....
> 
> Sure. Just put it into the webroot (<webroot> in <paths>). Icecast
> handles files in webroot according to your operating system's mine-
> type
> table.
> 
On Debian 9, in the configuration file it says:

<webroot>/usr/share/icecast2/web</webroot>
<ssl-certificate>/usr/share/icecast2/icecast.pem</ssl-certificate>

What should be the correct path of the icecast.pem file ?.
Should it be /usr/share/icecast2/web/icecast.pem ?.

Thanks.
> 
> > ie: http://icecast.domain.invalid/somestringofletersnumbers.txt
> > That they?
> > request if its dumped in the webroot stuff of Icecast? With out any
> > XSLT?
> > markup?
> 
> Icecast only processes XSLT files as XSLT.
> 
> 
> > So if I added a listening port on 80 for this, then took it away,?
> > since I don't use that for Icecast... Icecast is on its own server
> > which?
> > does not have Apache... web stuff for other things is on its own
> > box. I?
> > never have used the Icecast to server up anything other than the
> > default?
> > admin etc. stuff it does by default...
> 
> To avoid the need to run Icecast as privileged user in oder to bind
> to
> low ports (if Comodo really insists in using port 80) you can use
> your
> firewall to do a local redirect.
> 
> 
> Hope this is of help to you,
> 
> with best regards,
> 
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From epirat07 at gmail.com  Fri Jul 21 17:07:12 2017
From: epirat07 at gmail.com (Marvin Scholz)
Date: Fri, 21 Jul 2017 19:07:12 +0200
Subject: [Icecast] SSL Setup
In-Reply-To: <1500655290.1748.5.camel@speedy.com.ar>
References: <ojul1i$lu4$1@blaine.gmane.org>
 <1499685764.1836.3.camel@de.loewenfelsen.net>
 <1500655290.1748.5.camel@speedy.com.ar>
Message-ID: <2DE36FF3-3962-4F1C-B320-EE72F24DEF8C@gmail.com>



On 21 Jul 2017, at 18:41, Jos? Luis Artuch wrote:

> Hello !
>
> El lun, 10-07-2017 a las 09:31 +0000, Philipp Schafft escribi?:
>> Good morning,
>>
>>
>> On Mon, 2017-07-10 at 01:25 +0000, ScanCaster wrote:
>>> IceCast is one of the last services I have that doesn't connect
>>> securely,?
>>> and I am looking to close that hole....
>>> [...]
>>> OK... add a port for SSL for IceCast in icecast.xml...path for cert
>>> file?
>>> in same.... no biggie
>>
>> The <ssl-certificate> belongs in the <paths> section of the config
>> file.
>> (I'm not sure what you mean with 'in same', just wanted to make it
>> clear.)
>>
>>
>>> The key/cert needs to be in a dir and file with applicable
>>> permissions?
>>> for the IceCast user... no biggie..
>>>
>>> chown icecastusergroup:icecastusergroup??certfile
>>
>>
>>> What I am looking to confirm is that the cert file needs to
>>> contain:
>>>
>>> -----BEGIN RSA PRIVATE KEY-----
>>> MII
>>> -----END RSA PRIVATE KEY-----
>>>
>>> -----BEGIN CERTIFICATE-----
>>> MI
>>> -----END CERTIFICATE-----?
>>>
>>> Where the Cert is the file/text Comodo sends me, and the key is the
>>> one?
>>> openssl spit out earlier,?
>>>
>>> Combine them up in certfile, Correct? Special order?? KEY then
>>> Cert, or v-
>>> v? Line separating them?
>>
>> The format is the OpenSSL format: key, blank line, cert (chain).
>> echo | cat key.pem - cert.pem > combo.pem
>>
>>
>>> kill -HUP pidOfIcecast
>>
>> As of Icecast2 2.4.x you need to restart Icecast to reload the cert.
>> There is however a fix in 2.5.x (development) which is hopefully
>> released with the next development update.
>>
>>
>>> And good????
>>>
>>> One thing can the web server spit out just a text file that is used
>>> by?
>>> Comodo to verify ownership of the domain? The DNS method normally?
>>> fails....
>>
>> Sure. Just put it into the webroot (<webroot> in <paths>). Icecast
>> handles files in webroot according to your operating system's mine-
>> type
>> table.
>>
> On Debian 9, in the configuration file it says:
>
> <webroot>/usr/share/icecast2/web</webroot>
> <ssl-certificate>/usr/share/icecast2/icecast.pem</ssl-certificate>
>
> What should be the correct path of the icecast.pem file ?.
> Should it be /usr/share/icecast2/web/icecast.pem ?.

You certainly do not want to put your private key in your public webroot...

>
> Thanks.
>>
>>> ie: http://icecast.domain.invalid/somestringofletersnumbers.txt
>>> That they?
>>> request if its dumped in the webroot stuff of Icecast? With out any
>>> XSLT?
>>> markup?
>>
>> Icecast only processes XSLT files as XSLT.
>>
>>
>>> So if I added a listening port on 80 for this, then took it away,?
>>> since I don't use that for Icecast... Icecast is on its own server
>>> which?
>>> does not have Apache... web stuff for other things is on its own
>>> box. I?
>>> never have used the Icecast to server up anything other than the
>>> default?
>>> admin etc. stuff it does by default...
>>
>> To avoid the need to run Icecast as privileged user in oder to bind
>> to
>> low ports (if Comodo really insists in using port 80) you can use
>> your
>> firewall to do a local redirect.
>>
>>
>> Hope this is of help to you,
>>
>> with best regards,
>>
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From artuch at speedy.com.ar  Fri Jul 21 17:27:41 2017
From: artuch at speedy.com.ar (=?ISO-8859-1?Q?Jos=E9?= Luis Artuch)
Date: Fri, 21 Jul 2017 14:27:41 -0300
Subject: [Icecast] SSL Setup
In-Reply-To: <1500657006.2948.3.camel@gmail.com>
References: <ojul1i$lu4$1@blaine.gmane.org>
 <1499685764.1836.3.camel@de.loewenfelsen.net>
 <1500655290.1748.5.camel@speedy.com.ar> <1500657006.2948.3.camel@gmail.com>
Message-ID: <1500658061.2948.5.camel@speedy.com.ar>

El vie, 21-07-2017 a las 19:07 +0200, Marvin Scholz escribi?:
> 
> On 21 Jul 2017, at 18:41, Jos? Luis Artuch wrote:
> 
> > Hello !
> > 
> > El lun, 10-07-2017 a las 09:31 +0000, Philipp Schafft escribi?:
> > > Good morning,
> > > 
> > > 
> > > On Mon, 2017-07-10 at 01:25 +0000, ScanCaster wrote:
> > > > IceCast is one of the last services I have that doesn't connect
> > > > securely,?
> > > > and I am looking to close that hole....
> > > > [...]
> > > > OK... add a port for SSL for IceCast in icecast.xml...path for
> > > > cert
> > > > file?
> > > > in same.... no biggie
> > > 
> > > The <ssl-certificate> belongs in the <paths> section of the
> > > config
> > > file.
> > > (I'm not sure what you mean with 'in same', just wanted to make
> > > it
> > > clear.)
> > > 
> > > 
> > > > The key/cert needs to be in a dir and file with applicable
> > > > permissions?
> > > > for the IceCast user... no biggie..
> > > > 
> > > > chown icecastusergroup:icecastusergroup??certfile
> > > 
> > > 
> > > > What I am looking to confirm is that the cert file needs to
> > > > contain:
> > > > 
> > > > -----BEGIN RSA PRIVATE KEY-----
> > > > MII
> > > > -----END RSA PRIVATE KEY-----
> > > > 
> > > > -----BEGIN CERTIFICATE-----
> > > > MI
> > > > -----END CERTIFICATE-----?
> > > > 
> > > > Where the Cert is the file/text Comodo sends me, and the key is
> > > > the
> > > > one?
> > > > openssl spit out earlier,?
> > > > 
> > > > Combine them up in certfile, Correct? Special order?? KEY then
> > > > Cert, or v-
> > > > v? Line separating them?
> > > 
> > > The format is the OpenSSL format: key, blank line, cert (chain).
> > > echo | cat key.pem - cert.pem > combo.pem
> > > 
> > > 
> > > > kill -HUP pidOfIcecast
> > > 
> > > As of Icecast2 2.4.x you need to restart Icecast to reload the
> > > cert.
> > > There is however a fix in 2.5.x (development) which is hopefully
> > > released with the next development update.
> > > 
> > > 
> > > > And good????
> > > > 
> > > > One thing can the web server spit out just a text file that is
> > > > used
> > > > by?
> > > > Comodo to verify ownership of the domain? The DNS method
> > > > normally?
> > > > fails....
> > > 
> > > Sure. Just put it into the webroot (<webroot> in <paths>).
> > > Icecast
> > > handles files in webroot according to your operating system's
> > > mine-
> > > type
> > > table.
> > > 
> > 
> > On Debian 9, in the configuration file it says:
> > 
> > <webroot>/usr/share/icecast2/web</webroot>
> > <ssl-certificate>/usr/share/icecast2/icecast.pem</ssl-certificate>
> > 
> > What should be the correct path of the icecast.pem file ?.
> > Should it be /usr/share/icecast2/web/icecast.pem ?.
> 
> You certainly do not want to put your private key in your public
> webroot...
> 
Thanks Marvin. Is ok into any other directory, for example
/etc/icecast2/ssl ?.
> > 
> > Thanks.
> > > 
> > > > ie: http://icecast.domain.invalid/somestringofletersnumbers.txt
> > > > That they?
> > > > request if its dumped in the webroot stuff of Icecast? With out
> > > > any
> > > > XSLT?
> > > > markup?
> > > 
> > > Icecast only processes XSLT files as XSLT.
> > > 
> > > 
> > > > So if I added a listening port on 80 for this, then took it
> > > > away,?
> > > > since I don't use that for Icecast... Icecast is on its own
> > > > server
> > > > which?
> > > > does not have Apache... web stuff for other things is on its
> > > > own
> > > > box. I?
> > > > never have used the Icecast to server up anything other than
> > > > the
> > > > default?
> > > > admin etc. stuff it does by default...
> > > 
> > > To avoid the need to run Icecast as privileged user in oder to
> > > bind
> > > to
> > > low ports (if Comodo really insists in using port 80) you can use
> > > your
> > > firewall to do a local redirect.
> > > 
> > > 
> > > Hope this is of help to you,
> > > 
> > > with best regards,
> > > 
> > > 
> > > _______________________________________________
> > > Icecast mailing list
> > > Icecast at xiph.org
> > > http://lists.xiph.org/mailman/listinfo/icecast
> > 
> > _______________________________________________
> > Icecast mailing list
> > Icecast at xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From epirat07 at gmail.com  Fri Jul 21 17:44:28 2017
From: epirat07 at gmail.com (Marvin Scholz)
Date: Fri, 21 Jul 2017 19:44:28 +0200
Subject: [Icecast] SSL Setup
In-Reply-To: <1500658061.2948.5.camel@speedy.com.ar>
References: <ojul1i$lu4$1@blaine.gmane.org>
 <1499685764.1836.3.camel@de.loewenfelsen.net>
 <1500655290.1748.5.camel@speedy.com.ar> <1500657006.2948.3.camel@gmail.com>
 <1500658061.2948.5.camel@speedy.com.ar>
Message-ID: <D37877D9-4CC4-48E5-BF0F-A47BA8292C30@gmail.com>



On 21 Jul 2017, at 19:27, Jos? Luis Artuch wrote:

> El vie, 21-07-2017 a las 19:07 +0200, Marvin Scholz escribi?:
>>
>> On 21 Jul 2017, at 18:41, Jos? Luis Artuch wrote:
>>
>>> Hello !
>>>
>>> El lun, 10-07-2017 a las 09:31 +0000, Philipp Schafft escribi?:
>>>> Good morning,
>>>>
>>>>
>>>> On Mon, 2017-07-10 at 01:25 +0000, ScanCaster wrote:
>>>>> IceCast is one of the last services I have that doesn't connect
>>>>> securely,?
>>>>> and I am looking to close that hole....
>>>>> [...]
>>>>> OK... add a port for SSL for IceCast in icecast.xml...path for
>>>>> cert
>>>>> file?
>>>>> in same.... no biggie
>>>>
>>>> The <ssl-certificate> belongs in the <paths> section of the
>>>> config
>>>> file.
>>>> (I'm not sure what you mean with 'in same', just wanted to make
>>>> it
>>>> clear.)
>>>>
>>>>
>>>>> The key/cert needs to be in a dir and file with applicable
>>>>> permissions?
>>>>> for the IceCast user... no biggie..
>>>>>
>>>>> chown icecastusergroup:icecastusergroup??certfile
>>>>
>>>>
>>>>> What I am looking to confirm is that the cert file needs to
>>>>> contain:
>>>>>
>>>>> -----BEGIN RSA PRIVATE KEY-----
>>>>> MII
>>>>> -----END RSA PRIVATE KEY-----
>>>>>
>>>>> -----BEGIN CERTIFICATE-----
>>>>> MI
>>>>> -----END CERTIFICATE-----?
>>>>>
>>>>> Where the Cert is the file/text Comodo sends me, and the key is
>>>>> the
>>>>> one?
>>>>> openssl spit out earlier,?
>>>>>
>>>>> Combine them up in certfile, Correct? Special order?? KEY then
>>>>> Cert, or v-
>>>>> v? Line separating them?
>>>>
>>>> The format is the OpenSSL format: key, blank line, cert (chain).
>>>> echo | cat key.pem - cert.pem > combo.pem
>>>>
>>>>
>>>>> kill -HUP pidOfIcecast
>>>>
>>>> As of Icecast2 2.4.x you need to restart Icecast to reload the
>>>> cert.
>>>> There is however a fix in 2.5.x (development) which is hopefully
>>>> released with the next development update.
>>>>
>>>>
>>>>> And good????
>>>>>
>>>>> One thing can the web server spit out just a text file that is
>>>>> used
>>>>> by?
>>>>> Comodo to verify ownership of the domain? The DNS method
>>>>> normally?
>>>>> fails....
>>>>
>>>> Sure. Just put it into the webroot (<webroot> in <paths>).
>>>> Icecast
>>>> handles files in webroot according to your operating system's
>>>> mine-
>>>> type
>>>> table.
>>>>
>>>
>>> On Debian 9, in the configuration file it says:
>>>
>>> <webroot>/usr/share/icecast2/web</webroot>
>>> <ssl-certificate>/usr/share/icecast2/icecast.pem</ssl-certificate>
>>>
>>> What should be the correct path of the icecast.pem file ?.
>>> Should it be /usr/share/icecast2/web/icecast.pem ?.
>>
>> You certainly do not want to put your private key in your public
>> webroot...
>>
> Thanks Marvin. Is ok into any other directory, for example
> /etc/icecast2/ssl ?.

I think so, yes.

>>>
>>> Thanks.
>>>>
>>>>> ie: http://icecast.domain.invalid/somestringofletersnumbers.txt
>>>>> That they?
>>>>> request if its dumped in the webroot stuff of Icecast? With out
>>>>> any
>>>>> XSLT?
>>>>> markup?
>>>>
>>>> Icecast only processes XSLT files as XSLT.
>>>>
>>>>
>>>>> So if I added a listening port on 80 for this, then took it
>>>>> away,?
>>>>> since I don't use that for Icecast... Icecast is on its own
>>>>> server
>>>>> which?
>>>>> does not have Apache... web stuff for other things is on its
>>>>> own
>>>>> box. I?
>>>>> never have used the Icecast to server up anything other than
>>>>> the
>>>>> default?
>>>>> admin etc. stuff it does by default...
>>>>
>>>> To avoid the need to run Icecast as privileged user in oder to
>>>> bind
>>>> to
>>>> low ports (if Comodo really insists in using port 80) you can use
>>>> your
>>>> firewall to do a local redirect.
>>>>
>>>>
>>>> Hope this is of help to you,
>>>>
>>>> with best regards,
>>>>
>>>>
>>>> _______________________________________________
>>>> Icecast mailing list
>>>> Icecast at xiph.org
>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From omaclay at gmail.com  Fri Jul 28 17:46:17 2017
From: omaclay at gmail.com (Otis Maclay)
Date: Fri, 28 Jul 2017 12:46:17 -0500
Subject: [Icecast] ssl streaming cert error
Message-ID: <CAJf+y-pE+ZkTQs1oOOL6ED-41emNK6BgdWALmaxNTQv7z=VVyg@mail.gmail.com>

Hi,

I'm streaming on a secure site so the icecast server has to use ssl.
i had it working last year with no problem, using the same cert as the
server (same key, same cert in the pem file icecast had access to).
no problem
when the cert expired, i renewed and put new crt into the pem file so
icecast would be good for another year.
icecast claims the key is invalid.
or sometimes claims the crt is invalid.
they both check out with ssl, and that combination is working for the
server.
i'm stumped.
these certs are both working for the server, and the combination worked
last year.
the only change is the new cert.
permissions are ok.
if start icecast with the old pem, it still accepts it (but since the crt
has expired it flags that on browsers).

i could really use some wisdom here....

thanks for anything

Otis Maclay
--------------------------
Why not give veterans a monthly stipend when they walk in the door,..  THEN
figure out how much they're supposed to get?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170728/fa16e699/attachment.htm>