Certificados TLS en Webship: La CA ACME Incorporada

# Certificados TLS en Webship: La CA ACME Incorporada

Un certificado TLS realiza dos funciones: ayuda a cifrar una conexión y le indica al cliente con qué identidad está hablando. El cifrado puede ser fuerte mientras la decisión de confianza sea incorrecta para la audiencia. Es por eso que la automatización de certificados debe comenzar con una pregunta: ¿quién debe confiar en este sitio?

Webship 1.4.0 toma esa decisión de manera independiente para cada sitio configurado. Un sitio web público puede usar un certificado ACME confiable por el navegador, un servicio interno puede usar la autoridad de certificación privada integrada de Webship, y un sitio con una PKI existente puede mantener archivos de certificado gestionados por el operador. Todos pueden compartir un proceso de Webship sin compartir una clave privada ni un límite de confianza.

Cuatro modos de certificado automático, seleccionados por sitio

El campo certificate_mode pertenece a cada entrada de [[sites]]. No es un interruptor global.

| Modo | Fuente de confianza | Mejor ajuste | Ruta de validación | | --- | --- | --- | --- | | por_sitio | Almacenes de confianza públicos de navegador y sistema operativo | Un sitio público con un nombre de host exacto | ACME público con TLS-ALPN-01 | | flota | Almacenes de confianza de navegadores públicos y sistemas operativos | Grandes conjuntos de nombres de tercer y cuarto nivel bajo dominios registrados explícitamente | ACME público con DNS-01 y fragmentos de certificados estables | | incrustado | Una raíz de Webship privada instalada por el operador | Servicios internos, dispositivos gestionados, flotas privadas y entornos de prueba | Emisión en proceso; sin desafío externo | | compartido | Almacenes de confianza de navegador y sistema operativo públicos | Implementaciones heredadas que usan intencionalmente un grupo multi-SAN público | ACME público con TLS-ALPN-01 |

El valor predeterminado es per_site. Solicita un certificado público para el nombre exacto del sitio. El modo Fleet es la opción pública escalable para muchos subdominios profundos. El modo Embedded utiliza la CA privada en proceso de Webship. El modo Shared sigue estando disponible por compatibilidad, pero no es el predeterminado.

Un certificado y clave completos bajo [sites.tls] siempre tienen prioridad sobre la emisión automática para ese sitio.

Lo que significa “ACME CA incrustado”

La sección de configuración se llama [acme_ca], pero la CA integrada no es un servicio ACME público ni accesible por la red. No expone ningún endpoint de directorio, no acepta inscripción remota, no llama a ninguna API de registrador y no realiza ningún desafío de prueba de control.

En cambio, Webship mantiene toda la ruta de emisión privada en un solo proceso:

1. El sitio selecciona certificate_mode = "embedded".
2. Webship carga o crea la identidad raíz privada en el directorio de estado configurado.
3. Webship genera una nueva clave privada para el sitio.
4. La raíz incrustada firma un certificado de hoja para ese nombre exacto.
5. Webship valida la identidad completada antes de instalarla en el resolvedor TLS en vivo.
6. El certificado está entonces disponible para cada protocolo habilitado para ese sitio.

Un desafío de red al estilo ACME solo demostraría Webship a sí mismo, por lo que la ruta incrustada deliberadamente no tiene protocolo de red. La sección [acme_ca] es estado privado de PKI: define dónde se encuentra la raíz y cuánto tiempo permanecen válidos los certificados de hoja emitidos.

Configurar un certificado incrustado para un sitio

Esta es la forma mínima para un sitio privado:

~~~toml escuchar = "0.0.0.0:443"

[tls] unknown_sni = "rechazar"

[tls_automático] habilitado = verdadero cache_dir = "/var/lib/webship/acme"

[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90

[[sitios]] dominio = "service.internal.example" root = "/srv/service" certificate_mode = "incrustado"

[sitios.protocolo] h1 = verdadero h2 = verdadero h3 = verdadero ~~~

La identidad raíz se crea de manera perezosa cuando un sitio incorporado la necesita por primera vez. Webship persiste la clave raíz con permisos restrictivos en state_dir. El certificado raíz tiene una duración de diez años; la duración de las hojas se controla mediante leaf_validity_days.

Trate ambos lugares de almacenamiento como estado de producción:

• La caché ACME contiene identidades de sitio gestionadas automáticamente.
• El directorio de estado del CA integrado contiene la identidad raíz privada.
• La cuenta de servicio necesita acceso, pero los usuarios de la aplicación no.
• Las copias de seguridad deben preservar la confidencialidad y los permisos de los archivos.
• La producción, el desarrollo y las pruebas deben usar raíces separadas y directorios separados.

Eliminar el directorio raíz no “restablece TLS”. Crea un nuevo ancla de confianza. Los clientes que confían en el antiguo raíz rechazarán los certificados emitidos por el reemplazo hasta que se actualicen sus almacenes de confianza.

El fideicomiso privado es intencional

Los certificados de la CA incorporada no son confiables automáticamente por los navegadores públicos o los sistemas operativos. Solo se vuelven confiables después de que el operador instala el certificado raíz de Webship exportado en el almacén de confianza del cliente.

Eso hace que el modo incrustado sea adecuado para:

• portátiles y teléfonos gestionados por la empresa inscritos mediante la gestión de dispositivos;
• tráfico interno de servicio a servicio con un paquete de CA explícito;
• aparatos privados y flotas de borde controladas;
• entornos de desarrollo y prueba que deben ejercer un comportamiento TLS real;
• redes desconectadas que no pueden depender de una CA pública.

No es el modo adecuado para un sitio web público ordinario cuyos visitantes usan navegadores no gestionados. Use la emisión pública por sitio para un nombre público exacto, emisión para flotas para conjuntos grandes de subdominios públicos, compartido solo para un despliegue deliberado y heredado de múltiples SAN, o archivos manuales de una PKI ya confiable.

Distribuya solo el certificado raíz a los clientes. Nunca distribuya la clave privada raíz. La posesión de esa clave le da a su titular la autoridad para emitir identidades confiables para todos los clientes inscritos.

Los certificados públicos y privados pueden coexistir

Webship 1.4.0 puede mezclar estrategias de certificado en el mismo oyente:

~~~toml escuchar = "0.0.0.0:443"

[tls] unknown_sni = "rechazar"

[tls_automático] habilitado = verdadero directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contactos = ["mailto:ops@example.com"] aceptar_términos_de_servicio = verdadero

[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90

[[sitios]] dominio = "www.example.com" root = "/srv/public" certificate_mode = "por_sitio"

[[sitios]] dominio = "control.internal.example" root = "/srv/control" certificate_mode = "incrustado"

[[sitios]] dominio = "payments.example.com" root = "/srv/payments"

[sitios.tls] cert = "/etc/webship/payments-fullchain.pem" clave = "/etc/webship/payments-private-key.pem" ~~~

Aquí, www.example.com recibe su propio certificado ACME público. control.internal.example recibe un certificado privado de la CA integrada. payments.example.com permanece bajo la PKI externa del operador porque sus archivos explícitos tienen prioridad.

El directorio público de ACME es ignorado por los sitios incrustados. La raíz incrustada nunca firma el sitio público. El sitio manual nunca se inscribe silenciosamente en ningún flujo de trabajo automático.

Un solucionador de certificados para H1, H2, H3 y WebTransport

La selección del certificado ocurre durante el apretón de manos TLS, antes de que exista una solicitud HTTP. Webship utiliza el nombre del servidor en ClientHello para seleccionar la identidad del sitio y luego negocia el protocolo de aplicación.

• HTTP/1.1 y HTTP/2 usan TLS sobre TCP.
• HTTP/3 y WebTransport utilizan TLS dentro de QUIC sobre UDP.
• Una identidad de sitio válida puede servir para todos los protocolos habilitados.
• HTTP/3 también requiere accesibilidad UDP; H1 y H2 usan la ruta TCP.
• Alt-Svc puede anunciar H3 mientras conserva una alternativa de respaldo TCP.

TCP, TLS y QUIC usan el mismo modelo de identidad consciente del sitio. Los nombres exactos tienen prioridad, el comodín válido más largo gana donde se configuran certificados comodín, y el SNI con nombre desconocido puede ser rechazado en lugar de recibir un certificado predeterminado no relacionado.

Use unknown_sni = "reject" en un oyente multi-sitio cuando un nombre de host no reconocido deba fallar de forma cerrada. Pruebe nombres reconocidos, nombres no reconocidos y su comportamiento esperado sin SNI antes del despliegue en producción.

Rotar identidades incrustadas sin un intervalo de servicio

Webship expone el estado del certificado y las mutaciones controladas a través de su servidor MCP autenticado, enlazado a loopback:

• webship.tls.get_status informa sobre el resolvedor de certificados activo y el estado de renovación.
• webship.tls.reissue_certificate vuelve a emitir inmediatamente un sitio gestionado automáticamente solo cuando ese sitio utiliza el modo incrustado.
• webship.tls.reload recarga el estado del certificado a través de la ruta TLS protegida normal.
• webship.acme_ca.status informa si la CA privada está seleccionada, su directorio de estado, la duración de las hojas, el recuento de emisiones, el recuento de revocaciones y una muestra reciente de dominios.
• webship.sites.apply agrega o elimina sitios respecto a una versión de configuración fijada.

Para una reemisión integrada, Webship crea y valida el reemplazo antes de intercambiarlo en el servicio. La identidad válida actual sigue funcionando hasta que la nueva identidad esté lista. La identidad retirada se registra solo después de que se instala el reemplazo.

La operación de reemisión inmediata rechaza intencionalmente los certificados públicos por sitio. La renovación pública debe permanecer dentro del ciclo de vida público de ACME en lugar de confundirse con la firma privada en proceso. La membresía en modo compartido también está congelada para reinicios porque cambiar un grupo multi-SAN reconstruye el límite de identidad.

MCP es una superficie de control privilegiada. Manténgalo en bucle de retorno, requiera TLS y un token de portador fuerte, use un túnel autenticado para la administración remota y audite cada mutación.

Límites de fracaso que importan

Un sistema de certificados seguro debe fallar en la dirección correcta.

• Un sitio integrado recién configurado no recibe la identidad de otro sitio mientras la emisión está pendiente.
• No se instala un reemplazo inválido sobre un certificado que funciona.
• Los archivos manuales explícitos evitan la propiedad automática de ese sitio.
• Un SNI con nombre desconocido puede ser rechazado antes del enrutamiento HTTP.
• La CA incorporada permanece privada y no tiene un punto de inscripción remoto.
• Las identidades públicas e integradas utilizan rutas de caché separadas dentro del estado de TLS automático.

Una advertencia de que la CA incorporada no está inicializada significa que Webship no pudo preparar el directorio de estado configurado. Corrija la propiedad, los permisos, la persistencia o la disponibilidad del almacenamiento antes de enviar tráfico al sitio afectado. No intente solucionar el error copiando la clave raíz de otro entorno.

Lista de verificación de producción

Antes de habilitar el modo incrustado:

1. Identifique a toda la población de clientes que debe confiar en el sitio.
2. Cree un proceso controlado para exportar e instalar el certificado raíz.
3. Usa un estado raíz separado para producción, desarrollo y pruebas.
4. Persistir y proteger el directorio de estado de la CA incrustada y la caché TLS automática.
5. Ejecute Webship bajo una cuenta de servicio dedicada con acceso solo al material clave requerido.
6. Seleccione certificate_mode en cada sitio cuyo límite de confianza debe ser explícito.
7. Configurar y probar la política de SNI desconocido.
8. Habilite H1, H2 y H3 deliberadamente y verifique tanto las rutas TCP como UDP.
9. Ejercicio de reemisión, reinicio, copia de seguridad, restauración y validación de confianza del cliente fuera de producción.
10. Ejecute webship --check-config antes del despliegue, luego verifique el emisor, nombres, validez, cadena y protocolos negociados desde un cliente real.

Elige la confianza primero, la automatización después

La CA integrada elimina una dependencia de servicio de certificados externo para la infraestructura privada. No hace que una raíz privada sea confiable globalmente, y no elimina las responsabilidades de PKI del operador.

Webship automatiza la generación de claves, la firma, la validación, la instalación, la rotación y la selección de certificados en todo el protocolo. El operador aún posee la custodia raíz, la inscripción de clientes, la separación de entornos, la copia de seguridad, la recuperación y la decisión de usar una ruta de confianza pública o privada.

Esa separación es la característica. Un servidor autónomo puede automatizar TLS privado sin pretender ser una CA pública, y los sitios públicos aún pueden usar la emisión por sitio o por flota confiable por el navegador en el mismo proceso.

Lea la documentación versionada Webship 1.4.0 antes del despliegue. RFC 5280 define perfiles y validación de certificados, RFC 6066 define la señalización de nombre de servidor TLS, RFC 8446 define TLS 1.3, RFC 8555 define ACME público, y RFC 9525 define la verificación de identidad del servicio.