Los certificados TLS en un homelab tienen una habilidad especial para fallar en el peor momento. No fallan cuando estás tranquilamente revisando el dashboard. Fallan cuando necesitas entrar al gestor de contraseñas, cuando alguien quiere ver fotos, cuando estás fuera de casa o cuando acabas de tocar otra cosa y no sabes si el problema viene de DNS, del proxy, del navegador o de la madre que lo parió.
Durante bastante tiempo traté HTTPS interno como una capa estética. “Ya lo pondré bien”. “Total, esto solo lo uso yo”. “Acepto el warning y listo”. Es una forma bastante cómoda de acumular deuda técnica en silencio. El día que empiezas a tener más servicios, más móviles, más usuarios en casa o más automatizaciones, esos warnings dejan de ser una molestia y se convierten en ruido peligroso. Si el navegador grita siempre, cuando tenga razón no le vas a hacer caso.
Mi conclusión ahora es simple: en casa quiero HTTPS interno, pero no quiero vivir pendiente de certificados. El sistema tiene que renovar solo, avisar antes de romperse y ser lo bastante aburrido como para entenderlo seis meses después.
No busco una PKI de empresa en miniatura. Busco dormir tranquilo.
el problema no es crear el certificado#
Crear un certificado una vez es fácil. Renovarlo bien durante años es lo que separa una configuración decente de una chapuza bonita.
En un homelab típico empiezas con un servicio expuesto detrás de Nginx Proxy Manager, Traefik, Caddy o un reverse proxy similar. Pides un certificado, funciona, te sientes razonablemente adulto y pasas a otra cosa. Luego llega el segundo servicio, el tercero, el panel interno, el NAS, Home Assistant, Paperless, Immich, Vaultwarden, Uptime Kuma, algún dashboard, alguna API pequeña.
De pronto tienes certificados generados desde tres sitios distintos. Un proxy usa HTTP-01, otro usa DNS-01, un contenedor trae su propio ACME, un servicio usa certificado autofirmado y otro depende de un script que nadie recuerda. Todo va bien hasta que algo caduca.
El error habitual es tratar cada servicio como un caso independiente. A mí me parece mucho mejor diseñar la emisión de certificados como una pieza de infraestructura común. Igual que haces con DNS o backups. No es emocionante, pero precisamente por eso conviene dejarlo cerrado.
mi regla: pocos sitios pueden pedir certificados#
En casa intento que los certificados salgan de muy pocos sitios. Idealmente uno o dos.
El primer sitio suele ser el reverse proxy principal. Si un servicio web pasa por él, el proxy termina TLS y gestiona el certificado. El contenedor o la VM que hay detrás puede hablar HTTP por una red interna o HTTPS con un certificado propio si tiene sentido, pero el navegador de casa ve siempre el proxy.
El segundo sitio puede ser una herramienta de automatización para casos que no pasan por ese proxy: un NAS, una interfaz de administración, un servicio que exige su propio certificado o un equipo donde no quiero meter tráfico web normal. Ahí prefiero un cliente ACME claro, con configuración versionada y logs fáciles de mirar.
Lo que evito es que cada aplicación se convierta en su propia autoridad de certificados improvisada. Si cada cosa renueva a su manera, cada cosa fallará a su manera. Y no hay nada más divertido que depurar cinco maneras distintas de romper lo mismo. Bueno, sí lo hay: no hacerlo.
DNS-01 casi siempre gana en casa#
Para servicios internos, DNS-01 me parece la opción más limpia. No necesito abrir el puerto 80, no necesito que el servicio sea accesible desde fuera y puedo emitir certificados para nombres internos que resuelven solo dentro de mi red o por VPN.
El flujo es bastante sencillo: el cliente ACME demuestra que controla el dominio creando un registro TXT temporal en DNS. Let’s Encrypt o la autoridad que uses lo comprueba, emite el certificado y el registro se limpia después. El servicio final no tiene que exponerse públicamente.
Esto encaja muy bien con homelab porque muchas cosas deberían vivir detrás de VPN, Tailscale o LAN. No quiero publicar el panel del NAS, el dashboard de monitorización o el gestor de documentos solo para que un reto HTTP pueda verlo desde Internet. Prefiero que el dominio sea mío, que el DNS público pueda validar el control y que la resolución interna apunte a donde toca.
El precio de DNS-01 es que necesitas una API DNS fiable y un token con permisos. Y ahí hay que ser cuidadoso. Ese token no debería tener más permisos de los necesarios. Si el proveedor permite limitarlo a una zona concreta, mejor. Si permite limitarlo a edición de DNS sin tocar facturación, usuarios o zonas ajenas, mejor todavía.
No metería ese token en diez contenedores si puedo evitarlo. Prefiero centralizarlo en el proxy o en una VM pequeña de certificados. Menos copias del secreto, menos puntos donde olvidarlo.
nombres internos que no dan vergüenza#
El otro gran problema de HTTPS interno es el naming. Si los nombres son caóticos, los certificados terminan siendo caóticos.
Yo separaría nombres públicos y nombres internos desde el principio. Por ejemplo, los servicios que salen a Internet pueden vivir bajo servicio.tu-dominio.com. Los internos pueden vivir bajo servicio.home.tu-dominio.com o servicio.lan.tu-dominio.com. La parte exacta da un poco igual. Lo importante es que haya una convención y que no acabes con una mezcla de .local, IPs, nombres de host antiguos y dominios que ya no recuerdas por qué existen.
No usaría .local como base para certificados. .local pertenece al mundo mDNS y funciona bien para descubrimiento sencillo en redes domésticas, pero no es una estrategia seria para TLS con ACME público. Para certificados válidos de navegador necesitas un dominio real o una autoridad interna. Si ya tienes un dominio, úsalo con una subzona interna y split-horizon DNS si hace falta.
Split-horizon suena más grande de lo que es. Para mí significa que dentro de casa vault.home.tu-dominio.com resuelve a una IP interna y fuera de casa no resuelve o apunta a otra cosa. El certificado puede ser válido igualmente, porque la validación por DNS no depende de que el servicio web sea público.
Esta separación también ayuda mentalmente. Si un servicio está bajo home.tu-dominio.com, mi expectativa es que no sea público. Si está bajo la raíz pública, me obliga a pensar si de verdad debería estar expuesto.
wildcard sí, pero con cabeza#
Un wildcard como *.home.tu-dominio.com puede ser comodísimo. Un solo certificado sirve para muchos servicios internos y reduces bastante la gestión. Para un homelab pequeño, no me parece mala idea.
Pero el wildcard también invita a la pereza. Si todo cabe bajo el mismo certificado, puedes acabar añadiendo servicios sin pensar demasiado. Además, si alguien obtiene ese certificado y su clave privada, puede suplantar cualquier nombre de esa subzona.
Mi punto medio sería usar wildcard para servicios internos de bajo riesgo detrás de un proxy controlado. Para servicios más sensibles, como contraseñas o administración crítica, me gusta tener algo más explícito. No siempre por una diferencia técnica enorme, sino porque obliga a mirar dos veces.
También mantendría separadas las zonas. No usaría el mismo wildcard para servicios públicos y privados. Un certificado para *.tu-dominio.com puede ser cómodo, pero mezcla demasiadas cosas. Prefiero *.home.tu-dominio.com para interno y certificados concretos para lo público.
reverse proxy: Caddy, Traefik o Nginx Proxy Manager#
No hay una respuesta universal. Caddy es probablemente el más agradable si quieres que HTTPS funcione con poca configuración. Traefik encaja muy bien si tienes contenedores y etiquetas, especialmente con Docker o Kubernetes. Nginx Proxy Manager es cómodo si quieres UI y no te apetece tocar demasiado texto.
Yo elegiría por mantenimiento, no por moda.
Si el homelab es pequeño y casi todo vive en Docker Compose, Caddy o Nginx Proxy Manager son muy razonables. Si ya tienes muchos contenedores y quieres que los servicios se registren solos mediante labels, Traefik tiene sentido. Si estás en Kubernetes, cert-manager más un ingress controller puede ser lo lógico, pero no montaría Kubernetes solo para resolver certificados. Eso es poner una autopista para ir a comprar pan.
La clave es que el proxy tenga una configuración que puedas reconstruir. Si usas UI, exporta o documenta. Si usas archivos, versiónalos. Si usas secretos, apunta dónde viven y cómo se restauran. Un reverse proxy que solo existe dentro de una base de datos opaca puede funcionar años, pero el día de la restauración vas a agradecer haber dejado migas.
alertas antes de que caduque#
La renovación automática no basta. Quiero una alerta antes de que el certificado caduque.
No hace falta montar una barbaridad. Uptime Kuma puede comprobar certificados HTTPS y avisar con margen. Muchos clientes ACME exponen logs claros. Algunos proxies enseñan fecha de caducidad en la UI. Incluso un script pequeño que recorra una lista de URLs y avise si quedan menos de 21 días puede salvarte.
La alerta buena tiene que cumplir dos cosas: llegar por un canal que miro y no dispararse por tonterías cada día. Si me avisa demasiado, la ignoraré. Si me avisa tarde, no sirve. Para casa, me gusta una ventana de 21 o 14 días. Da tiempo a arreglar DNS, token, proxy o proveedor sin hacerlo corriendo.
También revisaría de vez en cuando los logs de renovación. No para leerlos por deporte, sino para comprobar que el sistema renueva de verdad y no vive del certificado emitido hace dos meses. Hay configuraciones que parecen sanas hasta que llega el primer ciclo real de renovación.
el plan B que suelo querer#
Cada servicio crítico debería tener una forma de acceso si el proxy o el certificado fallan.
No digo exponer paneles internos a lo loco. Digo saber cómo entrar desde LAN o VPN a la interfaz real del servicio, aunque sea con un certificado autofirmado temporal o una excepción consciente. Si el reverse proxy cae, quiero poder llegar al NAS, al host de virtualización, al gestor de contraseñas desde un dispositivo ya autenticado o a la monitorización mínima.
Esto se documenta en tres líneas por servicio: nombre, acceso normal, acceso de emergencia. No hace falta una novela. En mitad de una avería, una nota corta gana a un diagrama precioso.
También me gusta que DNS interno no dependa de una sola pieza frágil. Si todo resuelve gracias a un contenedor que vive detrás del mismo proxy que estás intentando arreglar, has creado una broma mala. Para servicios críticos, DNS y acceso administrativo tienen que sobrevivir a la caída de una parte razonable del homelab.
errores que intentaría evitar#
El primer error es mezclar certificados autofirmados, certificados públicos, dominios internos raros y excepciones de navegador sin una regla clara. Funciona hasta que no sabes qué comportamiento es normal.
El segundo es guardar tokens DNS en cualquier sitio. Un token que puede editar DNS es delicado. No lo metería en repositorios, notas sueltas o variables de entorno copiadas por medio homelab. Si el proxy necesita el token, que lo tenga el proxy. Y punto.
El tercero es renovar manualmente. Hacerlo una vez vale. Hacerlo como sistema es pedir que caduque cuando estés de viaje. Todo lo que tenga caducidad corta y sea necesario para entrar a servicios debería automatizarse o eliminarse.
El cuarto es no probar después de renovar. Algunos servicios cargan certificados al arrancar y no recargan solos. Otros tienen permisos raros sobre los archivos. Otros necesitan reiniciar un contenedor. Si el certificado se renueva pero el proceso sigue sirviendo el viejo, te enteras demasiado tarde.
cómo lo montaría desde cero#
Si empezara hoy, haría esto:
- Elegiría una subzona interna, por ejemplo
home.tu-dominio.com. - Configuraría DNS interno para que esos nombres apunten al reverse proxy o al servicio que toque.
- Usaría DNS-01 para emitir certificados sin exponer servicios internos.
- Centralizaría los certificados en el reverse proxy salvo excepciones claras.
- Guardaría tokens DNS con permisos mínimos.
- Añadiría monitorización de caducidad con alerta a 21 días.
- Documentaría acceso normal y acceso de emergencia para servicios críticos.
No es una arquitectura espectacular, pero ese es el punto. Los certificados no deberían ser la parte emocionante del homelab. Deberían ser fontanería fiable.
mi conclusión#
HTTPS interno merece la pena cuando deja de ser una colección de apaños. Si cada servicio tiene su certificado, su método de renovación, su nombre raro y su excepción de navegador, no has ganado seguridad real. Has ganado trabajo.
La versión que mejor me funciona es más aburrida: dominio propio, DNS-01, pocos emisores, reverse proxy claro, nombres internos coherentes y alertas antes de caducar. Con eso, los certificados pasan a ser una pieza más del sistema, no una avería mensual esperando fecha.
Y en un homelab doméstico eso vale mucho. Porque la infraestructura buena de casa no es la que impresiona en una captura. Es la que no te obliga a levantarte del sofá para arreglar HTTPS justo cuando alguien solo quería abrir una receta, ver una foto o entrar a un documento.