Con la nueva versión de Chrome (la 80, lanzada en febrero), se habilita por defecto el intento de llamar a todos los elementos multimedia vía https en páginas que carguen también bajo este protocolo, aunque en código la llamada se intente hacer vía http, sobreescribiendo esta llamada e intentando forzar cargar el contenido así junto al resto de la página. Esto no ocurre si la página carga bajo http. También está empezando a ocurrir en actualizaciones de otros navegadores móviles y de escritorio. Y, lamentablemente, esto está ocurriendo antes de que los sistemas habitualmente usados para transmisión de señales de radio (Shoutcast y Icecast), así como el panel Centovacast, estén adaptados todavía para ello.
Afortunadamente, esto todavía no ocurre con otros navegadores como Edge o Firefox. Tampoco si reproducimos la señal con cualquier software reproductor externo como VLC, Winamp… Tampoco con las aplicaciones móviles desarrolladas.
Compatiblidad SSL bajo Shoutcast e Icecast
A fecha de hoy, Shoutcast2 solo permite recibir la llamada vía https contratando una licencia adicional, y en Icecast2 (al menos en su versión pública oficial) se puede habilitar de forma manual bajo un puerto secundario. En el futuro se podrán habilitar ambos protocolos bajo el mismo puerto, pero esta funcionalidad todavía está en beta por parte de Icecast2.
Compatibilidad panel Centovacast
También dependemos de los desarrolladores del panel Centovacast, que todavía no tienen integrada esta opción (lo harán cuando se lance la versión final de Icecast 2.5). No obstante, antes, planean ofrecer una actualización intermedia para adelantar el soporte a este tipo de señales. Estamos en conversación con ellos constantemente para que sea lo antes posible.
Podemos ofrecer el servicio bajo https desde hoy mismo
A pesar de ello, nosotros estamos preparados para ofrecer el servicio realizando una configuración manual, tanto en Icecast2 (preferentemente), como incluso en Shoutcast2 a través de una pasarela intermedia. En caso de trabajar bajo Shoutcast2, recomendamos primero migrar a Icecast2 (manteniendo la dirección de escucha), para poder habilitar de forma nativa el protocolo SSL. Incluso para codificadores que solo permitan el envío a Shoutcast, podemos habilitar compatibilidad en el servicio Icecast2 para recepción desde protocolo Shoutcast, por lo que incluso en estos casos sería viable.
Todos nuestros planes actualizados, incluyen ya el acceso bajo protocolo seguro (https) sin coste adicional. Y es posible actualizar a estos planes para todos nuestros clientes, analizando cada caso de forma individual.
Migración y activación
Aunque es posible activarlo directamente también para servicios Shoutcast2, si es posible, recomendamos la migración a Icecast2 y activar el servicio bajo protocolo SSL de forma nativa. La migración e instalación del certificado la realizamos en pocos minutos, manteniendo los datos de emisión y recepción anteriores, y permitiendo recepcionar la señal bajo el mismo puerto (tanto bajo http como https). Recomendamos contactar con nosotros primero para analizar cada caso concreto y ver la mejor solución.
Soluciones en el futuro
La versión 2.5 de Icecast2 (todavía en Beta), solucionará estos problemas y, una vez publicada, Centovacast actualizará el panel para que este proceso se automático, gratuito y masivo. Algo similar a lo que ocurrió con los certificados para hosting, algo que hoy en día es automático y gratuito con los paneles de hosting como cPanel con los que también trabajamos. Actualmente, es necesario usar 2 puertos diferentes, pero con la nueva versión será suficiente con 1 puerto para ambos protocolos. Pero, mientras tanto, Google (y otros navegadores basados en Chromium) ya se han adelantado a bloquear este tipo de contenido sin cifrar. Durante este periodo de actualizaciones, podremos seguir ofreciendo señales bajo https, aunque sea a través de una versión no oficial de Icecast2 e instalando el certificado de forma manual.
También en servicio de enlace clásico
A partir del 9 de marzo, también habilitaremos la recepción bajo https en el servicio de enlace clásico. No obstante, en este servicio NO será necesario una URL secundaria para la recepción, se podrá llamar a la misma URL habitual, tanto con como sin https desde este momento.
Cómo forzar Chrome para evitar bloqueo señal http
También es posible realizar un ajuste un Chrome al cargar la página afectada, para permitir la ejecución de la fuente de audio vía https.
Para ello, debemos de pulsar en el candado a la izquierda del nombre de la página Web, y pulsar sobre «Configuración de sitio Web», como se muestra en la imagen:
Y una vez accedamos a la nueva ventana, abajo del todo, desplegar las opciones de «Contenido no seguro». Como vemos, por defecto está «Bloquear», y este es el problema. Podemos modificarlo para dejarlo en «Permitir». Una vez esto hecho, podemos cerrar y volver a nuestra página. Nos indicará que hay que recargar la página para aplicar los cambios de configuración, y al recargar, se escuchará de nuevo la señal correctamente.
Evidentemente, esta no es la mejor solución, y la deberían de aplicar todos los oyentes que usen Chrome. Por ello, disponemos ya de las soluciones indicadas arriba para los clientes que no quieran/puedan esperar a la actualización de Icecast2 y/o Centovacast en las próximas semanas.
