La app de Home Assistant cerrada con un certificado, con nginx o Caddy y sin Cloudflare

El mismo candado, tu propia puerta

La app de Home Assistant a través de Cloudflare, cerrada con un certificado pone el candado en el borde de Cloudflare. El móvil tiene un certificado, Cloudflare lo comprueba, y nada que no lo tenga llega a la casa. Funciona, es gratis, y significa que Cloudflare guarda la puerta y lee el tráfico al pasar.

Esto es el mismo candado con la puerta en tu propia casa. nginx o Caddy comprueba el certificado. Tu propia autoridad de certificación lo emite. No hay nadie más en el camino. La página de inicio de sesión sigue siendo invisible para todo lo que no tenga certificado, así que lo que cambia no es si entran desconocidos. Es quién hace el trabajo, y quién carga con el riesgo cuando sale mal.

Todo lo de aquí se construyó y se probó: nginx 1.30.5 y Caddy 2.11.7 en Podman, certificados de step-ca 0.30.2, cada proxy atacado sin certificado, con un certificado bueno, con uno revocado y con un upgrade a WebSocket, por IPv4 e IPv6. El backend de la prueba era un pequeño sustituto que devuelve las cabeceras que recibe, así que los resultados muestran exactamente lo que le llegaría a Home Assistant.

Qué cambia cuando Cloudflare se va

Las dos filas que más importan tiran en direcciones opuestas. Nadie más lee tu tráfico ni puede apagarte, y eso es soberanía, el motivo entero para hacerlo. Pero la redirección de puerto vuelve, así que los escaneos y las inundaciones dan contra tu línea en vez de contra la de Cloudflare. La diferencia con la redirección de puerto normal de la comparación de la entrada de Cloudflare es lo que encuentran al llegar: un proxy que corta la conexión durante el saludo, no la página de inicio de sesión de Home Assistant.

Ten claro lo que eso compra y lo que no. Tu propio proxy inverso no te da ninguna protección contra DDoS. mTLS impide que entre un desconocido. No hace nada para impedir que un desconocido te llene la línea, y una inundación no necesita certificado para llenarla. Cloudflare te absorbe eso en todos los planes, el gratuito incluido¹. Aquí no hay nadie delante que lo absorba, así que una inundación lo bastante grande deja a toda la casa sin internet, y el proxy solo puede rechazar las conexiones que llega a ver.

nginx o Caddy

Los dos hacen el trabajo. Se diferencian en un sitio que importa. La revocación.

La revocación es lo que hay que decidir. La documentación de Caddy lista exactamente un verificador incluido en el Caddy estándar, leaf, y comprueba si el certificado «is one of a defined set of permitted certificates»². No hay CRL ni OCSP para certificados de cliente. Apunta Caddy solo a la CA y un móvil revocado entra como si nada. La prueba mostró justo eso: phone2, revocado una hora antes, recibió un 200. La lista de permitidos cierra el hueco. También es una lista que mantienes a mano, mientras lo tengas funcionando.

La configuración de nginx

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name ha.example.com;

    ssl_certificate         /etc/nginx/pki/server-chain.pem;
    ssl_certificate_key     /etc/nginx/pki/server.key;
    ssl_protocols           TLSv1.2 TLSv1.3;

    # The mTLS half: only certificates from our CA, and not revoked.
    ssl_client_certificate  /etc/nginx/pki/client-ca.pem;
    ssl_verify_client       on;
    ssl_verify_depth        2;
    ssl_crl                 /etc/nginx/pki/crl-chain.pem;

    location / {
        proxy_pass http://192.0.2.10:8123;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

El archivo de la CRL es la parte que requiere cuidado, y está todo en Certificados de cliente de step-ca: por qué se rechaza la CRL de step-ca hasta que una plantilla arregla su alcance, por qué nginx también quiere una CRL de la raíz, y el temporizador que la refresca antes de que caduque. Sáltate eso y nginx deja fuera a todos los móviles, los buenos incluidos.

Lo que devolvió la prueba:

Antes de añadir listen [::]:8443, la petición IPv6 ni siquiera conectaba. Salida 7 de curl.

La configuración de Caddy

ha.example.com {
	tls /etc/caddy/pki/server-chain.pem /etc/caddy/pki/server.key {
		client_auth {
			mode require_and_verify
			trust_pool file /etc/caddy/pki/client-ca.pem
			verifier leaf {
				file /etc/caddy/pki/allowed-phones.pem
			}
		}
	}
	reverse_proxy 192.0.2.10:8123
}

require_and_verify significa que el certificado tiene que estar y tiene que encadenar hasta la CA². verifier leaf es la revocación. Solo entran los certificados de allowed-phones.pem, así que revocar un móvil significa sacar su certificado de ese archivo y recargar.

La lista de permitidos tiene su propia trampa, y la prueba se metió de lleno en ella. La lista guarda certificados exactos, no nombres. Vuelve a emitir el certificado de un móvil y el nuevo no está en la lista. phone1 se volvió a emitir a mitad de las pruebas y Caddy lo rechazó con tls alert bad certificate hasta que se reconstruyó la lista. Ahora cada renovación son dos trabajos. Emitir el certificado, y luego actualizar la lista. Olvida el segundo y el móvil se queda fuera para nada.

Caddy también registra enabling strict SNI-Host enforcement because TLS client auth is configured al arrancar. Es él haciendo lo correcto: una petición tiene que pedir el mismo nombre de host en el saludo que en la petición HTTP, para que nadie pueda pasar la comprobación de certificado de un sitio y luego pedir otro.

El lado de Home Assistant

Los mismos ajustes que en la versión de Cloudflare, apuntando a otro proxy. En Settings → System → Network → HTTP server⁴:

Lista la dirección IPv6 del proxy además de la IPv4. La prueba muestra a nginx reenviando ::1 como dirección del cliente por IPv6, y en uso reenvía la que traiga el móvil. Si Home Assistant solo confía en la dirección IPv4 del proxy, toda petición que le llegue del proxy por IPv6 se rechaza.

El móvil

De step-ca, el móvil necesita tres archivos. Está todo en la entrada de certificados de cliente de step-ca, y la configuración de la propia CA en Tu propia autoridad de certificación.

El certificado de servidor del proxy también viene de step-ca. La app de Home Assistant para Android confía en los certificados de CA que instala el usuario⁶, así que lo acepta, y eso es un segundo candado, no una molestia. Un dispositivo que no tiene tu raíz no confía en el servidor, antes incluso de que se plantee la cuestión de su propio certificado.

Luego pon el nivel de seguridad de conexión de la app en Most secure, igual que en la versión de Cloudflare⁷.

Dónde se queda corto

Nada de esto está escondido. Cada cosa es un trabajo. Apúntalo con una fecha o un comando al lado y se queda en trabajo, no en sorpresa.

Que todo sea tuyo

La versión de Cloudflare y esta dejan fuera al mismo desconocido. La diferencia es en quién tienes que confiar mientras lo hacen.

Con Cloudflare confías en que una empresa guarde la puerta, descifre el tráfico y siga ofreciéndolo gratis. Con esto confías en ti mismo para refrescar una CRL, tener una lista en orden y darte cuenta cuando llega una fecha. Ninguna está libre de confianza. Una la reparte a alguien a quien no pagas nada y a quien no puedes llamar. La otra la deja en casa, donde puedes verla fallar y arreglarla.

Para la puerta de una casa, sé cuál prefiero. El trabajo son unos pocos archivos y un temporizador. Como tal, lo único que de verdad pide es que lo cuides, que es lo que siempre ha significado que algo sea tuyo.