Por qué necesitás HTTPS en desarrollo
Desarrollar sobre HTTP en 2024 no es solo mala práctica: rompe funcionalidad real. APIs modernas como Service Workers, Push Notifications, getUserMedia (cámara/micrófono), Geolocation, y Clipboard requieren contexto seguro (HTTPS) para funcionar. Chrome y Firefox bloquean estas features en HTTP desde hace años.
Otro problema: el comportamiento de cookies cambió. SameSite=None (necesario para cookies cross-site) requiere flag Secure, que solo funciona en HTTPS. Si tu app usa autenticación con cookies entre subdominios o integraciones OAuth, vas a tener bugs en producción que no aparecen en desarrollo HTTP.
Mixed Content es otro dolor de cabeza: si tu app final corre en HTTPS pero desarrollás en HTTP, no vas a detectar requests bloqueados a recursos HTTP (imágenes, scripts, APIs). Esto genera bugs silenciosos que solo aparecen en producción.
Finalmente, diferencias de red entre HTTP y HTTPS afectan performance: HTTP/2 solo está disponible sobre TLS, y características como Server Push y multiplexing se comportan diferente. Testear sobre HTTP te da métricas falsas de velocidad.
mkcert: la herramienta que deberías usar
Olvidate de comandos OpenSSL complicados. mkcert es una herramienta Go que genera certificados confiables localmente en un solo comando, instalando su propia CA en el trust store de tu sistema.
Instalación: brew install mkcert (Mac), choco install mkcert (Windows), o apt install mkcert (Linux). Luego mkcert -install para instalar la CA local (solo una vez).
Generar certificado: mkcert localhost 127.0.0.1 ::1 crea dos archivos (localhost.pem y localhost-key.pem) que funcionan inmediatamente en Chrome, Firefox, Safari y Edge sin warnings de seguridad.
Para wildcards: mkcert '*.myapp.local' cubre todos los subdominios. Esto es útil para arquitecturas multi-tenant o cuando testeas con subdominios dinámicos.
Ventajas sobre OpenSSL: no tenés que editar archivos de config, no hay que importar manualmente CAs en cada navegador, funciona out-of-the-box con herramientas como curl y wget, y los certificados son válidos automáticamente en todos los browsers que respeten el system trust store.
Para CI/CD: mkcert no es para producción, solo desarrollo. En pipelines, usá certificados autofirmados con OpenSSL y configurá el cliente HTTP para ignorar validación SSL (solo en tests, nunca en prod).
Certificados con Subject Alternative Names (SAN)
Los certificados modernos requieren SAN (Subject Alternative Names) para especificar múltiples dominios. El campo CN (Common Name) está deprecado desde 2017 y Chrome/Firefox lo ignoran.
Para generar un cert con SAN en OpenSSL (sin mkcert), necesitás un archivo de configuración. Comando rápido: openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365 -subj '/CN=localhost' -addext 'subjectAltName=DNS:localhost,DNS:*.localhost,IP:127.0.0.1'
Esto crea un certificado válido para localhost, todos sus subdominios (*.localhost), y la IP 127.0.0.1. Esencial si tu app usa tanto localhost como 127.0.0.1 indistintamente (común en Docker).
Para wildcards: DNS:*.example.local cubre sub.example.local pero NO example.local. Tenés que incluir ambos: DNS:example.local,DNS:*.example.local.
Error común: olvidar incluir la IP. Si tu app hace requests a https://127.0.0.1:3000, necesitás IP:127.0.0.1 en el SAN, no solo DNS:localhost.
Para verificar SANs en un certificado existente: openssl x509 -in cert.pem -text -noout | grep 'Subject Alternative Name' -A 1
Configuración en frameworks y servidores
Node.js/Express: El módulo https nativo acepta options con key y cert. Cargá los archivos con fs.readFileSync(). Para desarrollo, usá https-localhost (npm package) que genera certificados automáticamente.
Next.js: Creá un server.js custom con https.createServer, o usá el package next-https. En next.config.js no hay soporte nativo para HTTPS en dev server, necesitás wrapper.
Vite: En vite.config.js, agregá: server: { https: { key: fs.readFileSync('key.pem'), cert: fs.readFileSync('cert.pem') } }. Mejor aún, instalá @vitejs/plugin-basic-ssl que genera certificados automáticamente.
React (Create React App): Setea HTTPS=true en .env. CRA genera su propio certificado autofirmado, pero vas a tener warnings en el browser. Para evitarlos, generá uno con mkcert y apuntá con SSL_CRT_FILE y SSL_KEY_FILE.
Docker: Montá los certificados como volumes: -v ./cert.pem:/app/cert.pem -v ./key.pem:/app/key.pem. En docker-compose, usá volumes: - ./cert.pem:/app/cert.pem:ro (read-only para seguridad).
Nginx: En tu server block, ssl_certificate y ssl_certificate_key apuntan a tus archivos. Agregá ssl_protocols TLSv1.2 TLSv1.3; y ssl_ciphers HIGH:!aNULL:!MD5; para buenas prácticas.