¿Necesitas mostrar un sitio de demostración alojado en Windows Server 2022 totalmente aislado y quieres evitar las alarmas de seguridad de los navegadores? En esta guía entenderás por qué un certificado autofirmado no basta y cómo lograr una experiencia “sin avisos” para tus clientes.
Problema planteado
El escenario de laboratorio o “road show” es habitual: un servidor fuera de dominio, sin conexión a Internet y que viaja físicamente a las oficinas del cliente. El objetivo es presentar aplicaciones web en condiciones realistas, pero los avisos “Your connection isn’t private” deterioran la percepción de calidad y generan desconfianza.
Por qué los navegadores no confían en los certificados autofirmados
Cada navegador incorpora de fábrica (en su trust store) las Autoridades de Certificación (CA) públicas que han superado rigurosas auditorías. Un certificado autofirmado —o uno expedido por tu propia CA interna— no aparece entre esas raíces. El resultado es una advertencia irreversible hasta que el usuario instale manualmente la raíz desconocida.
Opciones disponibles
| Opción | Ventajas | Inconvenientes |
|---|---|---|
| Certificado de CA pública (Let’s Encrypt, DigiCert…) | Confianza total y automática en todos los navegadores modernos. Let’s Encrypt es gratuito. | Requiere validación de dominio: necesidad de exponer DNS público o delegar registros. |
| CA interna + distribución de la raíz | Control absoluto. Emisión ilimitada de certificados aun sin Internet. | Cada equipo visitante debe importar la raíz. No viable para dispositivos fuera de tu control. |
| Autofirmado puro | Generación inmediata con una sola orden. | El aviso de seguridad persiste; útil solo para desarrolladores. |
Conclusiones clave
- No existe un certificado autofirmado “mágico” que elimine los avisos sin instalar la raíz en cada cliente.
- Para entornos donde tú controlas el hardware, montar tu propia CA es aceptable.
- Cuando el cliente aporta sus propios equipos, lo práctico es usar una CA pública; Let’s Encrypt con validación DNS es la vía más barata y sencilla.
Recomendaciones prácticas según el tipo de demostración
Demos internas o con dispositivos bajo tu control
- Crea una CA raíz (ver guía paso a paso).
- Emite un certificado para el FQDN o IP del servidor.
- Importa la raíz en todos los portátiles, tablets y móviles que participarán en la demo. Así, el navegador confiará sin avisos.
Demos en casa del cliente con sus equipos
Aquí no podrás tocar su parque de dispositivos. La solución es usar un certificado de CA pública:
- Genera el certificado con Let’s Encrypt antes del viaje usando validación DNS. El CRT y la clave privada se guardan en tu maletín junto con el servidor.
- El certificado durará 90 días; suficiente para giras cortas.
¿El servidor no puede exponer un DNS público?
Considera llevar un pequeño reverse proxy (NGINX, Caddy o Apache) en una Raspberry Pi o portátil. Este proxy, sí conectado a Internet, renueva el certificado y, mediante tareas programadas, exporta un PFX que copias (USB o Ansible Pull) al servidor principal, que permanece aislado.
Guía paso a paso — CA interna + distribución manual
1. Generar la CA raíz
New‑SelfSignedCertificate -KeyExportPolicy Exportable `
-KeyLength 4096 -KeyUsage CertSign,CRLSign,DigitalSignature `
-FriendlyName "DemoRootCA" -Subject "CN=DemoRootCA" `
-CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(5)2. Exportar la raíz
Abre certlm.msc, localiza “DemoRootCA” en Personal, botón derecho > All Tasks > Export. Selecciona formato .CER (DER).
3. Instalar la raíz en los clientes
En cada portátil:
- Ejecuta mmc.exe > Archivo → Agregar o quitar complemento → Certificados (equipo local).
- Navega a Entidades de certificación raíz de confianza → Certificados.
- Importa el .CER.
4. Emitir el certificado del servidor
New‑SelfSignedCertificate -DnsName "demo-server.local" `
-CertStoreLocation "Cert:\LocalMachine\My" `
-Signer (Get-ChildItem Cert:\LocalMachine\My\ |
Where-Object {$_.Subject -eq "CN=DemoRootCA"})5. Exportar e instalar en IIS
- Desde certlm.msc exporta el nuevo certificado como .PFX con su clave privada.
- En el Server Manager o directamente en IIS, importa el PFX y asígnalo al binding HTTPS de tu sitio.
Automatización con PowerShell Remoting
Si despliegas laboratorios con frecuencia, puedes encadenar los pasos anteriores en un script que:
- Compruebe si existe la CA, y la cree si no.
- Emita certificados para todos los bindings activos en IIS.
- Sincronice la raíz hacia una carpeta compartida lista para que los asistentes la descarguen (código QR o URL interna).
Uso de Let’s Encrypt antes de desconectar el servidor
Let’s Encrypt requiere contacto con sus servidores ACME para validar la titularidad del dominio. Para un entorno offline:
- Contrata o reutiliza un dominio (ej.
mi-demo.cloud). Crea un subdominiosrv.mi-demo.cloud. - Usa el cliente Win-ACME o Certbot en modo DNS-01. El cliente mostrará los registros TXT a crear; publícalos en tu DNS público y lanza --test para validar.
- Al finalizar, exporta el PFX y cópialo al servidor que viajará.
Cuando el certificado caduque, repite el procedimiento en tu oficina; no es necesario que el servidor demo se conecte a Internet nunca.
Preguntas frecuentes
¿Puedo “convertir” un autofirmado en un certificado válido?
No. La única forma de que un certificado sea universalmente confiable es que la firma provenga de una CA cuya raíz ya esté en los almacenes de los navegadores.
¿Qué pasa si uso la IP en lugar del nombre DNS?
Los navegadores modernos solo confían en certificados cuyo Subject Alternative Name contenga la IP o el FQDN que aparece en la barra de direcciones. Incluir la IP en el campo SAN es admisible, pero no resuelve la falta de confianza para un autofirmado.
¿Cuál es la longitud ideal de la clave?
4096 bits RSA es buena práctica para raíces internas y ofrece holgura de seguridad. Para certificados de servidor se acepta 2048 bits, pero usar 4096 bits no suele impactar el rendimiento perceptiblemente en entornos demo.
¿Puedo usar ECC en vez de RSA?
Sí. Windows Server 2022 admite algoritmos ECC, pero asegúrate de que todos los dispositivos cliente los soporten; algunos sistemas embebidos o navegadores antiguos podrían no reconocerlos.
Buenas prácticas adicionales
- Establece un plazo de expiración corto (máximo 1 año) para tus certificados de servidor internos. Así evitas olvidar renovarlos y presentarte en la demo con un certificado caducado.
- Guarda la clave privada de la CA en un almacén protegido (TPM o al menos un pendrive cifrado con BitLocker) y mantenla fuera del servidor de demostración.
- Documenta quién, cuándo y por qué se generaron los certificados; incluso en un entorno demo interesa la trazabilidad.
- Automatiza verificaciones previas: un script que abra
https://localhostmedianteInvoke-WebRequesty analice posibles errores de certificado evita sorpresas in situ.
Conclusión ejecutiva
Un certificado autofirmado nunca obtendrá confianza universal sin intervención en los clientes. Para demos donde controlas el hardware, montar tu propia CA y distribuir su raíz es suficiente; para demos en casa del cliente, la única vía “sin avisos” es emplear un certificado de CA pública (Let’s Encrypt con validación DNS resulta imbatible en coste y simplicidad). Define tu estrategia antes de viajar y evitarás pantallas rojas que arruinen la primera impresión.