Cómo instalar Jitsi Meet en Ubuntu 24.04 con SSL de Let's Encrypt

Instalar Jitsi Meet en Ubuntu 24.04 es sencillo si el nombre DNS, el cortafuegos y el plan TLS son correctos antes de ejecutar el instalador. La guía oficial de Jitsi para autoalojamiento, actualizada por última vez el 10 de agosto de 2026, es compatible con Ubuntu 22.04 o versiones posteriores, por lo que Ubuntu 24.04 LTS se encuentra dentro del rango de compatibilidad documentado. La misma guía recomienda usar un certificado TLS de confianza y sugiere Let's Encrypt como la opción preferida durante la instalación.

Esta guía utiliza meet.example.orgcomo ejemplo el nombre de host. Reemplácelo en todas partes con el nombre de dominio completo que apunta a su servidor.

¿Qué debes tener preparado antes de instalar Jitsi Meet?

Necesitas un servidor Ubuntu 24.04 con acceso de superusuario (sudo), un nombre DNS público y acceso de red entrante para los puertos que requiere Jitsi. Jitsi es un servicio WebRTC en tiempo real, por lo que un servidor que pueda servir una página web pero no pueda recibir tráfico multimedia UDP no constituye una instalación completa.

• Ubuntu 24.04 LTS con acceso administrativo.
• Un registro DNS A que meet.example.orgapunte, por ejemplo, a la dirección IPv4 pública del servidor.
• Los puertos TCP 80 y 443 son accesibles desde Internet.
• El puerto UDP 10000 es accesible para el tráfico multimedia normal de Jitsi.
• Acceso SSH, normalmente TCP 22 a menos que lo hayas cambiado.
• Control suficiente de cualquier firewall en la nube, grupo de seguridad, enrutador o dispositivo NAT ascendente para reenviar los mismos puertos.

La documentación de Jitsi también indica que el puerto UDP 3478 se utiliza para consultas STUN cuando está habilitado, y el puerto TCP 5349 para el tráfico de respaldo TURN. Si el servidor se encuentra detrás de NAT, la configuración del firewall debe ser correcta tanto en Ubuntu como en el enrutador o la red en la nube.

¿Es necesario que el nombre de host se resuelva antes de que Let's Encrypt pueda funcionar?

Sí. Primero, crea el registro DNS y espera a que los servidores DNS públicos devuelvan la dirección pública del servidor. Let's Encrypt debe poder validar el control del nombre de host, y la configuración de Nginx de Jitsi también utilizará ese nombre de host.

Para una implementación típica, cree un registro A:

Desde el servidor, verifique que el nombre se resuelva como se espera:

getent ahostsv4 meet.example.org

Si devuelve una dirección incorrecta, deténgase aquí y corrija el DNS. Emitir un certificado antes de que el DNS sea correcto suele provocar fallos de validación evitables.

¿Qué paquetes base y repositorios de Ubuntu son necesarios?

La guía actual de Jitsi para Debian/Ubuntu enumera gnupg2, nginx-full, curlo wget, y sudocuando se usa sudo. También dice que se debe usar OpenJDK 17. Jitsi depende de paquetes del universerepositorio de Ubuntu.

sudo apt update
sudo apt install apt-transport-https
sudo add-apt-repository universe
sudo apt update
sudo apt install gnupg2 nginx-full curl

El apt-transport-httpspaquete se mantiene aquí porque sigue apareciendo en las instrucciones de inicio rápido de Jitsi. En las versiones modernas de Ubuntu, el protocolo HTTPS ya está integrado en APT, por lo que instalar dicho paquete podría considerarse más bien un paso de compatibilidad que la activación de una función que de otro modo no estaría disponible.

¿Cómo se añaden los repositorios de Prosody y Jitsi?

Jitsi utiliza Prosody para la señalización XMPP. La guía de inicio rápido oficial actualmente indica a los administradores que añadan tanto el repositorio de paquetes de Prosody como el repositorio estable de Jitsi.

sudo curl -sL https://prosody.im/files/prosody-debian-packages.key   -o /usr/share/keyrings/prosody-debian-packages.key

echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" |   sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list

sudo apt install lua5.2

curl -sL https://download.jitsi.org/jitsi-key.gpg.key |   sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'

echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" |   sudo tee /etc/apt/sources.list.d/jitsi-stable.list

sudo apt update

No sustituya estos repositorios por un PPA de terceros arbitrario. Utilizar las fuentes de paquetes documentadas por Jitsi reduce el riesgo de mezclar paquetes incompatibles de Jitsi, Prosody y Ubuntu.

¿Qué puertos del firewall deben abrirse antes de la instalación?

Abra los puertos necesarios antes de solicitar el certificado para que la validación HTTP pueda llegar al servidor y los medios puedan fluir después de la instalación. Para UFW, la guía actual de Jitsi establece estas reglas:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 22/tcp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable
sudo ufw status verbose

Si SSH utiliza un puerto diferente, habilítelo en lugar de agregar TCP 22 sin más. En una máquina virtual en la nube, duplique las reglas necesarias en el firewall o grupo de seguridad del proveedor. En un servidor detrás de un enrutador, reenvíe los puertos necesarios al host Ubuntu.

¿Cómo se instala Jitsi Meet y se elige Let's Encrypt?

Instala el metapackage desde el repositorio de Jitsi:

sudo apt install jitsi-meet

El instalador solicita el nombre de host de Jitsi. Introduzca el nombre DNS público, por ejemplo meet.example.org, . La documentación actual de Jitsi indica que la instalación también presenta opciones de certificados SSL/TLS y recomienda Let's Encrypt. Seleccione Certificado Let's Encrypt cuando se muestre esa opción.

Esto es preferible a tratar un script de certificado independiente antiguo como un paso universal. La guía de inicio rápido actual centra la selección del certificado en el flujo de instalación del paquete. Si el paquete instalado se comporta de manera diferente a lo que indica la documentación actual, no invente una solución: revise las indicaciones del paquete y la documentación de Jitsi específica de la versión antes de modificar manualmente los archivos de Nginx o de certificado.

¿Cómo se puede confirmar que HTTPS y la página de la reunión funcionan correctamente?

Ábrelo https://meet.example.orgdesde un navegador fuera del servidor. Si la implementación es exitosa, la página de Jitsi Meet debería cargarse sin mostrar ninguna advertencia de certificado del navegador. Crea una sala temporal y únete desde un segundo dispositivo o red.

La prueba del segundo cliente es importante porque cargar la página de inicio solo demuestra que HTTPS funciona. No demuestra que el tráfico multimedia de Jitsi Videobridge sea accesible. Si dos participantes pueden conectarse pero no pueden oírse ni verse, revise primero el puerto UDP 10000 y cualquier regla de NAT o firewall en la nube.

¿Qué servicios debería comprobar después de la instalación?

Jitsi Meet se compone de varios componentes en lugar de un servicio monolítico. Los componentes comunes en una instalación de paquete incluyen Nginx, Prosody, Jicofo y Jitsi Videobridge. Compruébelos individualmente:

sudo systemctl --no-pager --full status nginx prosody jicofo jitsi-videobridge2

También puede inspeccionar los sockets de escucha:

sudo ss -lntup | grep -E ':80|:443|:10000'

Si un servicio no está activo, lea sus registros antes de reinstalar paquetes repetidamente. La guía de inicio rápido de Jitsi indica específicamente a los administradores que consulten /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log, y /var/log/prosody/prosody.logpara la resolución de problemas.

¿Qué ocurre si el servidor está detrás de NAT?

La documentación de Jitsi indica que Videobridge debería configurarse automáticamente al arrancar cuando el servidor está detrás de NAT, siempre que se reenvíen los puertos necesarios. Si las llamadas a tres bandas siguen fallando, la guía documenta una asignación estática de direcciones locales a públicas en /etc/jitsi/videobridge/jvb.conf:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "<Local.IP.Address>"
          public-address = "<Public.IP.Address>"
        }
      ]
    }
  }
}

Utilice esta opción únicamente cuando coincida con la topología de su red. Una máquina virtual alojada con una dirección IP pública asignada directamente podría no necesitar la asignación, mientras que una máquina virtual privada detrás de una NAT uno a uno o un enrutador doméstico sí podría necesitarla.

¿Debería un servidor Jitsi con acceso a Internet permitir que cualquiera cree salas?

No necesariamente. La instalación predeterminada permite que cualquier persona con acceso al servidor inicie una conferencia. Para una organización privada, un aula o un servicio interno, esto puede resultar demasiado permisivo. La documentación actual de Jitsi recomienda configurar el acceso autenticado cuando se necesite restringir quién puede crear salas. Considere la autenticación como un paso de seguridad adicional una vez confirmada la implementación básica de HTTPS.

Lista de verificación para la resolución rápida de problemas

¿Cómo debería ser una implementación exitosa de Ubuntu 24.04?

Un resultado satisfactorio va más allá de simplemente indicar que la instalación se ha completado. El nombre DNS debe resolverse a la dirección pública prevista, el navegador debe cargar Jitsi mediante HTTPS de confianza, Nginx y los componentes de Jitsi deben estar activos, y un segundo participante debe poder intercambiar audio y vídeo. Si estas comprobaciones se superan, se habrán validado las rutas web, TLS, de señalización y de medios básicas más importantes en una implementación de un solo servidor.

Para obtener información detallada sobre la instalación, consulte la guía oficial de Jitsi para Debian/Ubuntu . Para obtener información sobre la arquitectura y una guía de implementación más completa, consulte la descripción general oficial de Jitsi para el autoalojamiento . Si los usuarios deben conectarse a través de redes con restricciones, revise la documentación oficial de configuración de TURN de Jitsi .