Skip to content

Certificado HTTPS

Mientras no cuelgue un certificado de uno de sus puertos, el streamer sirve HTTP plano. Esta página recorre todo el camino desde una máquina desnuda hasta un https:// que funciona — y repasa las razones por las que la emisión no arranca.

Los certificados viven en los streamers, y cada uno emite el suyo: central no guarda claves privadas ajenas. Lo que se configura aquí es el documento de configuración del streamer, así que sobrevive a una reinstalación de la máquina.

Qué hace falta antes de empezar

Let's Encrypt no emite nada hasta que se cumplen las tres condiciones:

  • Un nombre de dominio. ACME no emite para una IP pelada — https://45.41.213.34 no se obtiene de ninguna CA pública. Hace falta un nombre que usted controle.
  • DNS que ya apunte a este streamer. La autoridad de certificación resuelve el nombre y se conecta a quien responda. Apunte el registro A/AAAA a la máquina antes de pedir el certificado, no después.
  • El puerto 443 alcanzable desde internet. Aquí es donde más se falla, así que conviene ser exactos sobre cómo funciona la validación.

Catena valida con TLS-ALPN-01: la prueba se sirve dentro del handshake TLS, en el mismo puerto que lleva el tráfico. De ahí dos consecuencias:

  • El puerto 80 no hace falta en absoluto. No hay ruta HTTP de desafío, nada que abrir, nada que redirigir. Si su intuición dice «Let's Encrypt necesita el puerto 80» — eso es otro tipo de desafío, y no es el que se usa aquí.
  • El puerto tiene que ser el 443. La CA de producción solo ejecuta TLS-ALPN-01 contra el puerto 443. Un certificado configurado en 8443 no se emitirá nunca: se queda en «emitiéndose» sin error, porque la CA jamás llega hasta él. El formulario avisa de esto, pero es la forma más común de quedarse atascado.

TLS-ALPN-01 tampoco sobrevive a un proxy que termine TLS delante del streamer: el handshake debe llegar al streamer mismo.

Activar la emisión automática acepta en su nombre el acuerdo de suscriptor de Let's Encrypt; el streamer registra una cuenta ACME la primera vez que la pide.

Emitir un certificado de Let's Encrypt

Abra el streamer desde el registro y baje hasta la sección Certificados al pie de su ficha.

La sección de certificados antes de la primera entrada

Pulse Activar HTTPS. Una sola acción recorre toda la cadena de requisitos: añade un listener en el puerto 443 y le cuelga una entrada de Let's Encrypt. El certificado siempre vive en un puerto — por eso el listener hace falta primero, y por eso el botón lo crea por usted.

Ahora rellene la entrada:

Una entrada de Let's Encrypt con sus dominios y el correo ACME

  • Dominios — separados por comas. Son los nombres que cubrirá el certificado, y por los que los clientes lo eligen mediante SNI. Bajo el campo el formulario sugiere el hostname de las direcciones del propio streamer; es una sugerencia y se aplica solo al hacer clic, así que un campo vacío significa honestamente que el nombre aún no está puesto.
  • Correo de contacto ACME — obligatorio. Sin él no se emite nada, y el botón Guardar cambios sigue inactivo. La CA envía allí además los avisos de caducidad.

Deje Avanzado en paz: una URL del directorio ACME vacía significa el Let's Encrypt de producción.

La fila de puertos de arriba muestra el resultado — un chip marcado tls es un puerto que lleva certificado:

La fila de listeners con el puerto TLS

Pulse Guardar cambios. La configuración viaja a la máquina; la traza de aplicación muestra hasta dónde llegó.

Comprobar el resultado

El estado de la emisión aparece junto a la propia entrada y se repite en la ficha de certificados de la parte superior. Tres estados, y no se solapan:

  • emitiéndose — el pedido está en curso. Normal durante los primeros segundos tras guardar.
  • emitido — con el plazo restante; dos semanas antes de caducar la fila se pone amarilla. La renovación es automática y cambia el certificado sin volver a enlazar el puerto, así que no se corta nada.
  • fallido — con el motivo, literal de la CA.

Una emisión fallida con su motivo

Una entrada cuyo certificado aún no se ha emitido no sirve nada: el handshake a sus dominios se rechaza en lugar de responder con un certificado equivocado.

Enviar a los espectadores por https

El certificado en el puerto no cambia por sí solo las direcciones que se entregan a los reproductores. Si la URL pública de payload en Conexión y entrega sigue siendo http://, a los espectadores se los sigue enviando en claro y el certificado queda sin usar — el formulario lo dice sin rodeos. Cambie esa base a https:// con el nombre que cubre el certificado.

Lo mismo vale para la URL de la API del streamer: tras el primer certificado conviene pasar a https:// también las llamadas del propio central.

Su propio certificado

Elija PEM estático como fuente de la entrada cuando el certificado venga de otro sitio — su CA corporativa, una de pago, o un wildcard que usted mismo obtuvo.

Ambos campos aceptan o bien el texto PEM completo, o bien una ruta a un archivo en el streamer:

  • Pegue el PEM y central lo reparte a las máquinas. Así se distribuye un único certificado wildcard entre muchos streamers, y es la única manera de usar un wildcard aquí: ACME solo los emite por DNS-01, y Catena no lo hace.
  • Indique rutas y el streamer lee los archivos del disco. Rótelos con Ansible o con lo que sea; el streamer los relee sin reiniciarse y sin cortar conexiones.

Tenga en cuenta lo que implica pegar el PEM: la clave privada queda entonces en el documento de configuración del streamer y la API la devuelve entera al leerlo. El acceso de lectura a ese documento equivale al acceso de escritura a la configuración — trátelo en consecuencia.

Un certificado autofirmado para el banco de pruebas

Autofirmado hace que el streamer genere el certificado él mismo. No necesita DNS, ni un puerto alcanzable, ni una CA, así que es la manera de probar TLS en una red interna donde ACME no está disponible en absoluto. Los clientes mostrarán un aviso de confianza — es lo esperado, y por eso no es una opción de producción.

Un certificado autofirmado nunca sustituye a una emisión fallida de Let's Encrypt. El fallo sigue siendo un fallo visible, en vez de degradarse en silencio a un aviso para cada espectador.

Límites que conviene conocer

Let's Encrypt permite 50 certificados por registered domain cada 7 días, y el límite se cuenta globalmente entre todas las cuentas. Que cada streamer emita el suyo no lo esquiva: cien streamers bajo un mismo example.com chocan con el techo en el primer despliegue, y este se repone a razón de unos siete al día. Las renovaciones en régimen estable — una docena por semana para un clúster así — quedan muy por debajo.

Si el primer despliegue supera el límite:

  • obtenga usted mismo un certificado wildcard y repártalo como PEM estático;
  • o apunte el campo URL del directorio ACME a otra CA — es un camino soportado, no un apaño;
  • o pida a Let's Encrypt un aumento del límite, semanas antes del despliegue.

Para bancos de pruebas use el interruptor CA de pruebas (staging) en Avanzado: emite un certificado no confiable, pero no gasta el límite de producción. Cambiar de CA reinicia la emisión desde cero — la cuenta y el material se guardan por cada URL de directorio, así que una cuenta de staging nunca llega a la CA de producción.

Una consecuencia de elegir el certificado por SNI: no hay certificado por defecto. Una petición al puerto TLS por dirección IP, o con un nombre desconocido, ve su handshake rechazado. Los chequeos de salud que sondean el puerto por IP dejan de funcionar — apúntelos a un nombre que cubra el certificado.

Cuando la emisión no arranca

Se queda en «emitiéndose» para siempre. Por orden de probabilidad: la entrada no está en el puerto 443; el DNS del dominio no resuelve a este streamer; el puerto 443 está cerrado desde fuera; algo termina TLS delante del streamer.

Se rechaza el guardado. Una entrada letsencrypt sin correo de contacto se rechaza entera — el streamer responde que el listener «has a letsencrypt tls entry but no acme section is configured». Rellene el correo. Dos entradas en un mismo puerto que reclamen el mismo dominio también se rechazan, igual que una entrada estática con certificado pero sin clave privada.

Se rechaza el puerto en sí. El error se muestra junto al puerto que lo provocó. La causa habitual es un puerto ya ocupado por otro proceso de la máquina.

La consola dejó de abrirse tras activar HTTPS. El documento de configuración es dueño de la lista de puertos por completo: en cuanto contiene un listener, el puerto inicial de la máquina deja de aplicarse. Si todos los puertos HTTP de la lista llevan TLS, el HTTP plano deja de responder — y en la máquina que ejecuta central la consola se sirve precisamente de esos puertos. El formulario avisa cuando en la lista no queda ningún puerto plano; mantenga el puerto HTTP plano junto al 443 salvo que quiera deliberadamente solo HTTPS.

El certificado está emitido pero los espectadores siguen yendo por http. Las direcciones de entrega son independientes del certificado — vea Enviar a los espectadores por https.