MENU
  1. Inicio
  2. Windows
  3. Windows Server
  4. CA interna en Windows Server 2019: cómo habilitar HTTPS sin advertencias

CA interna en Windows Server 2019: cómo habilitar HTTPS sin advertencias

Windows Server

Dentro de una red corporativa, habilitar HTTPS con una CA interna permite cifrar el tráfico y eliminar los avisos de seguridad en los navegadores sin depender de entidades públicas externas, manteniendo el control total sobre los certificados y su ciclo de vida.

Índice

Ventajas de emplear una CA interna

Una autoridad de certificación (CA) privada en Windows Server 2019 ofrece:

  • Coste cero: no paga a proveedores externos por cada certificado.
  • Control y auditoría: define las directivas de emisión, revocación y renovación.
  • Emisión inmediata: genera certificados en minutos, incluso de forma automática.
  • Flexibilidad: crea plantillas personalizadas para aplicaciones web, VPN, LDAPS o confianza de dispositivos.

Concepto de cadena de confianza

Para que un navegador declare «sitio seguro», debe construir correctamente la cadena de confianza:

  1. Certificado del servidor (CN o SAN coincidente con el FQDN).
  2. Certificado intermedio (si se utiliza una CA subordinada).
  3. Certificado raíz de la CA interna, presente en el almacén Entidades de certificación raíz de confianza del sistema operativo cliente.

Si falta cualquiera de estos elementos, aparecerá el candado rojo o la advertencia “La conexión no es privada”.

Distribuir la raíz de la CA a todos los equipos

Conseguir que miles de dispositivos confíen en su CA es sencillo si se usa Active Directory:

MétodoÁmbitoVentaja principalRecomendado para
GPO Trusted Root Certification AuthoritiesDominios/OUAutomático y centralizadoEquipos unidos a AD
Script de inicio (CertUtil /addstore)Equipos concretosFlexible, sin reinicioLaboratorios, DMZ
Distribución MDM (Intune, JAMF)Dispositivos móvilesSoporta BYODiOS, Android
Instalación manualEquipo individualSin infraestructura adicionalPruebas puntuales

Pasos básicos con GPO

  1. Abra Group Policy Management y cree (o edite) una GPO.
  2. Navegue a Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies.
  3. Haga clic con el botón derecho en Trusted Root Certification Authorities > Import y seleccione el certificado .cer de la raíz.
  4. Vincule la GPO a la OU o dominio adecuados y ejecute gpupdate /force en los clientes.

Emitir un certificado de servidor correcto

El certificado SSL/TLS debe cumplir:

  • Plantilla adecuada: por ejemplo, Web Server con los EKU Server Authentication (1.3.6.1.5.5.7.3.1).
  • Nombre común (CN) o Subject Alternative Name (SAN) que coincida con https://miportal.corp.local (o un comodín si procede).
  • Clave RSA ≥ 2048 bits o ECC equivalente.

Solicitud con la consola MMC

En el servidor IIS:

  1. Ejecute mmc.exe > Certificates > Personal > Certificates.
  2. All Tasks > Request New Certificate y seleccione la plantilla.
  3. Especifique los SAN deseados (Add… > DNS).
  4. Complete la solicitud y, si la plantilla lo permite, el certificado se emite al instante.

Solicitud con PowerShell (autoenrollment)

Get-Certificate `
  -Template "WebServer" `
  -DnsName "miportal.corp.local","www.miportal.corp.local" `
  -CertStoreLocation Cert:\LocalMachine\My

Vincular el certificado en IIS

  1. Abra Internet Information Services (IIS) Manager.
  2. Seleccione el sitio > Bindings… > Add.
  3. Escoja Type = https, Port = 443, y el certificado recién emitido.
  4. Guarde y reinicie el sitio.

Flujo de confianza en la práctica

Una vez desplegados la raíz y el certificado del servidor:

  1. El cliente se conecta a https://miportal.corp.local.
  2. El servidor envía su certificado.
  3. El cliente busca la CA raíz en su almacén. Al hallarla, establece la sesión TLS y muestra el candado sin advertencias.

Verificación y solución de problemas

  • PowerShell: Invoke-WebRequest https://miportal.corp.local -UseBasicParsing debe devolver StatusCode 200 sin errores de certificado.
  • Chrome/Edge: pulse F12 > Security para ver la cadena de certificados.
  • Event Viewer: consulte Applications and Services Logs > Microsoft > Windows > CertificateServicesClient-Lifecycle-System para fallos de autoenrollment.
  • openssl: en un cliente Linux, ejecute openssl s_client -connect miportal.corp.local:443 -showcerts para revisar la cadena.

Renovación y mantenimiento

Planear con antelación evita cortes de servicio:

  • Duración del certificado: 1‑2 años es habitual; más corto favorece la seguridad.
  • Auto‑renovación: habilite Autoenroll en la GPO para servidores y clientes.
  • Supervisión: use System Center o Azure Monitor para alertar 30 días antes del vencimiento.
  • CRL y AIA: asegure rutas HTTP normalmente accesibles incluso fuera de la red (VPN) si los certificados se utilizan de forma remota.

Automatizar la revocación y la publicación de CRL

Configure la CA para:

  1. Publicar la CRL cada 7‑14 días (certutil -crl).
  2. Habilitar Delta CRL para reflotar cambios en minutos.
  3. Replicar las CRL a varias ubicaciones (DFS, IIS redundante) para alta disponibilidad.

Buenas prácticas de seguridad de la CA

  • Servidor offline: mantenga la CA raíz sin conexión y use una CA subordinada online.
  • Restrinja acceso a la consola de la CA mediante Role-Based Administration.
  • Habilite auditoría: registre la emisión y revocación de certificados.
  • Aplicar parches: incluya la CA en su ciclo normal de actualizaciones de Windows.

Preguntas frecuentes

¿Puedo usar un certificado wildcard (*.corp.local) con mi CA interna?
Sí, si su plantilla lo permite. Sin embargo, valore la segmentación por servicio para limitar el impacto de una clave comprometida.

¿Qué ocurre con dispositivos que no están en el dominio?
Necesitan que importe manualmente la raíz o emplee MDM. Sin ella, seguirán viendo advertencias.

¿El mensaje “El nombre no coincide” aparece aunque la raíz sea confiable?
Ese error se debe a que el CN o los SAN del certificado no coinciden con la URL solicitada. Emita de nuevo el certificado con los nombres correctos.

¿Puedo forzar HTTPS en todo IIS?
Use HTTP Strict Transport Security (HSTS) en la cabecera de respuesta o la opción Require SSL en SSL Settings del sitio.

Conclusión

Configurar una CA interna en Windows Server 2019 para habilitar HTTPS es un proyecto asequible y altamente beneficioso para la seguridad. La clave del éxito reside en distribuir la raíz de confianza a todos los dispositivos, emitir certificados de servidor correctamente configurados y automatizar la renovación. Con estos pasos, los usuarios disfrutarán de conexiones cifradas sin advertencias ni fricciones.

Windows Server
Certificados HTTPS Windows Server CA interna
Índice