Certificados Let’s Encrypt en redes privadas domésticas

29 Jun

Pues sí, al final lo he conseguido. A partir de ahora tengo servicios en la red casera que pueden cifrar sus conexiones sin tener que montar una autoridad de certificación.

Son necesarias algunas disposiciones para que todo pueda funcionar correctamente:

  • El certificado Let’s Encrypt debería ser de tipo comodín (wildcard) aunque no es imprescindible.
  • La creación y renovación de certificados debe ser (ahora sí obligatoriamente) efectuada mediante DNS para su validación. Dado que algunas de las máquinas tienen IP interna no pueden atender peticiones HTTP procedentes del exterior.
  • Las máquinas de la red doméstica que sirven contenido (las únicas en las que merece la pena aplicar este mecanismo) deben tener una IP fija.

En el caso de ejemplo estoy utilizando mi dominio taquiones.net en el que he creado un certificado digital que cubre taquiones.net y *.taquiones.net. Es decir, el principal y cualquier cosa que cuelgue por debajo de él. La zona DNS está definida con normalidad y apunta a máquinas externas que tengo en alquiler con sus alias (CNAMES) y demás, a la que he añadido registros con los nombres de las máquinas internas apuntando a direcciones IP internas. Sí, un DNS público puede responder con direcciones internas. No hay nada raro aquí porque en realidad ninguno de los enrutadores de Internet va a transmitir nada con esas IP.

  • portico.taquiones.net responde a 192.168.100.1 y es el router OpenWRT que me da acceso a la red.
  • matraz.taquiones.net responde a 192.168.100.2 y es un servidor de medios y copias empleando Debian .
  • falcata.taquiones.net responde a 192.168.100.3 y es una máquina de escritorio con algunos servicios añadidos.

Y así puedo seguir con todo aquello que me interese pero teniendo siempre en cuenta que esta disposición no es para que se pueda acceder desde fuera a estas máquinas. El DNS responde con direcciones internas que únicamente tienen sentido si se accede desde dentro de la red. En caso de necesitar acceso desde fuera hay que hacerlo de otra forma (VPN, DNS dinámico, …) pero no es lo que yo pretendo.

Después transfiero los archivos de certificados (fullchain.pem y privkey.pem) a los servidores internos y los distintos programas que puedan aceptar conexiones cifradas de manera que cuando, desde dentro de la red, se solicite acceso a matraz.taquiones.net, el DNS externo responderá con su IP interna y el servidor (pongamos que Apache) se presenta como una máquina bajo el amparo de *.taquiones.net. Y ya está. La conexión es segura porque el certificado raíz de Let’s Encrypt ya está instalado en el sistema y no hay queja por ninguna parte. Se pueden enviar contraseñas y datos sin temor a que algún invitado de la red pueda inspeccionar los paquetes.

Es cierto que direcciones como matraz.home me gustan más que matraz.taquiones.net pero es un precio pequeño a pagar por no tener que poner en marcha un certificado autofirmado y luego instalarlo en cada cliente.

El caso OpenWRT

El router que proporciona direcciones IP, servicio DNS y salida a la red tiene alguna peculiaridad. Para empezar a proteger el acceso a la aplicación web de gestión (luci) es necesario hacer dos cosas:

  1. Instalar el paquete luci-app-uhttpd que instala el servidor uhttpd y lo añade como servicio.
  2. Convertir los dos archivos .pem del certificado a formato .der para que los pueda usar uhttpd.

Para convertir dichos archivos empleamos el programa openssl (para variar) con las siguientes combinaciones:

$ # Para el certificado con la cadena completa
$ openssl x509 -inform pem -in fullchain.pem -outform der -out fullchain.der
$ # Para la clave privada
$ openssl rsa -inform pem -in privkey.pem -outform der -out privkey.der

Ambos archivos se pueden copiar en el directorio /etc/config (por ejemplo) y luego configurar el servicio uhttpd para que los emplee en el menú correspondiente.

Situación de la configuración de uHTTPd en el menú

Opciones clave de la configuración de uHTTPd

Hay que prestar atención a esos ajustes: forzar conexiones para que sean cifradas y permitir acceso desde direcciones IP privadas. La ruta de los certificados también debe elegir cuidadosamente porque si se sitúan en un directorio temporal, que sea borrado en cada arranque, el programa deja de funcionar por las bravas.

Referencias