A veces, durante el proceso de desarrollo web, se necesita un entorno seguro en el navegador, es decir, HTTPS. Una forma práctica de hacerlo es instalar una CA local y automatizar la emisión de certificados para cualquier subdominio de lcl.host y localhost. Esto es una alternativa más funcional y conveniente a los certificados autofirmados.
Para instalar una CA local existen herramientas como lcl.host y mkcert, las cuales ayudan a configurar y usar HTTPS rápidamente en el entorno de desarrollo.
Aunque mkcert es relativamente conocido, lcl.host apareció en marzo de 2024. En cierto modo, es una herramienta más conveniente, ya que configura HTTPS en modo interactivo de la consola con solo unos pocos clics (más adelante se explica).
HTTPS en el Entorno de Desarrollo
En la documentación de lcl.host se explica que el HTTPS local puede ser útil al desarrollar los siguientes servicios:
- Sitios web y aplicaciones públicas. En este caso, hay un certificado público en producción, y queremos imitar este entorno localmente.
- SaaS. Servicios en internet, por ejemplo, un proyecto SaaS en Ruby on Rails.
- Microservicios. Por ejemplo, una aplicación en React se conecta a una API de backend independiente, estableciendo cookies y realizando peticiones API.
El HTTPS local resuelve una serie de problemas en el desarrollo web real:
- Contenido mixto. En un mundo ideal, todo el contenido se transmite por HTTPS. Lamentablemente, en el mundo real, una página web protegida puede solicitar contenido no protegido por HTTP. Por lo tanto, es necesario agregar HTTPS al entorno local para imitar el contenido mixto en producción.
- Errores CORS. Cuando una página web carga contenido de varios orígenes, el contexto de seguridad del navegador puede cambiar, lo que provocará un error CORS. Al mantener el mismo contexto de seguridad en el navegador que en producción, se pueden reproducir y depurar problemas CORS localmente.
- HTTP/2. HTTP/2 y HTTP/3 requieren (o no permiten evitar) el uso de TLS.
- Cookies seguras. Por lo general, los navegadores trabajan con las cookies en localhost de la misma forma que en producción, a excepción de las cookies seguras (con el atributo Secure, que limita el ámbito de aplicación de las cookies). Para que el comportamiento de los navegadores sea igual, es necesario usar HTTPS en el entorno local de forma similar a la producción.
- OAuth y puntos finales seguros de terceros. Muchas organizaciones externas requieren HTTPS para los puntos finales incluso en el desarrollo local.
- Aplicaciones y mercados en el host local. Algunas herramientas que ejecutan un servidor web en un puerto local y se abren en el navegador a través de http://localhost:[PORT], a veces requieren HTTPS, al igual que los mercados como Heroku, Slack y AWS (al desarrollar aplicaciones para el mercado).
- Requisitos de las herramientas. Algunas herramientas de desarrollo requieren HTTPS para funcionar correctamente.
Comparación con los Certificados Autofirmados
Por lo general, en el entorno de desarrollo se utilizan certificados autofirmados, pero tienen algunas desventajas:
- Todos los miembros del equipo deben crear (y volver a crear) manualmente sus propios certificados autofirmados.
- Los certificados autofirmados deben agregarse manualmente a cada repositorio de confianza del sistema.
- Los dominios app.localhost no funcionan en todas partes, por lo que para los clientes que no son de navegador (por ejemplo, curl) se requieren entradas en /etc/hosts o un servidor DNS de desarrollo.
- Ejecutar aplicaciones en contenedores locales requiere actualizaciones constantes de los certificados y el repositorio de confianza.
El sistema lcl.host con una CA privada resuelve estos problemas, porque se instala en los directorios del sistema de certificados de confianza, lo que garantiza la universalidad del funcionamiento en diferentes entornos y dentro, fuera e incluso entre contenedores, y la compatibilidad con ACME permite configurar la emisión y renovación automáticas de los certificados. Los nombres de host funcionan en todas partes, sin ninguna configuración. Aquí está el mismo contexto de seguridad del navegador que en producción, sin las peculiaridades del navegador en el contexto de localhost.
La configuración del programa no requiere conocimiento del formato de los certificados ni de los principios de su funcionamiento.
Para configurar HTTPS en el desarrollo, debe instalar el kit de herramientas Anchor CLI, ejecutar anchor lcl y simplemente seguir las instrucciones.
brew install anchordotdev/tap/anchor
anchor lcl

En Windows, debe instalar el administrador de paquetes Chocolatey, y desde ahí, Anchor y lcl:
choco install anchor --version=0.0.22
anchor lcl
Después de ejecutar el programa, la mayoría de las instrucciones para configurar el entorno HTTPS consisten en presionar Enter, ingresar los nombres de dominio, copiar el código en la ventana del navegador, etc., como en el ejemplo básico:
~/codigonautas-app $ anchor lcl
# Signin to Anchor.dev `anchor auth signin`
# Signin to Anchor.dev `anchor auth signin`
| Please sign up or sign in with your Anchor account.
# Signin to Anchor.dev `anchor auth signin`
| Please sign up or sign in with your Anchor account.
|
| Once authenticated, we can provision your personalized Anchor resources to
| power HTTPS in your local development environment.
- Copied your user code WMFB-CWKC to your clipboard.
- Opened https://anchor.dev/users/sign_in/cli?signup_src=lclhost in your browser.
....


lcl.host se puede comparar con la herramienta mkcert, que también está diseñada para crear certificados dev de confianza local con nombres arbitrarios. También crea una CA privada local ya durante el proceso de instalación:
$ mkcert -install
Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊
$ mkcert example.com "*.example.com" example.test localhost 127.0.0.1 ::1
Created a new certificate valid for the following names 📜
- "example.com"
- "*.example.com"
- "example.test"
- "localhost"
- "127.0.0.1"
- "::1"
The certificate is at "./example.com+5.pem" and the key at "./example.com+5-key.pem"
Como se menciona en la documentación, lcl.host combina una CA privada administrada de Anchor, una zona DNS para resolver subdominios en el sistema local y la utilidad de línea de comandos Anchor CLI para administrar los almacenes de confianza locales. Cabe señalar que la CA administrada de Anchor ya es un servicio pago. La diferencia entre lcl.host y la herramienta mkcert es que los pasos de configuración en lcl.host están automatizados al máximo en la interfaz de usuario de la consola interactiva.
En cualquier caso, la CA local es una alternativa más funcional a los certificados autofirmados en el entorno de desarrollo.