Qué vas a conseguir
Que los portátiles y móviles gestionados se conecten a la Wi-Fi corporativa (y a la VPN) con un certificado en lugar de la contraseña del usuario: sin ventanas de credenciales, sin contraseñas de Wi-Fi guardadas en el móvil personal y con revocación al retirar el dispositivo. Dos caminos para emitirlos; eliges uno.
Antes de empezar
- Dispositivos enrolados y conformes (guía de Intune).
- El RADIUS/NPS o el controlador Wi-Fi configurados para EAP-TLS confiando en la CA que emitirá (lo hace quien gestiona la red; necesita el certificado raíz del paso 2).
- Camino A (NDES): una CA empresarial de Windows (AD CS) en marcha, un servidor Windows para NDES y el conector de certificados de Intune. Más piezas, pero reutiliza la PKI que ya tienes.
- Camino B (Cloud PKI): licencia Intune Suite o el complemento Cloud PKI. Sin servidores; Microsoft aloja la CA.
1. Elegir el camino y crear la CA
Con Cloud PKI, dos clics dan la raíz y la emisora, y la URI de SCEP que usarás en el paso 3. Con NDES el equivalente es: plantilla de certificado en AD CS para NDES, servidor NDES con el rol instalado, conector de Intune en ese servidor, y la URL pública del NDES (normalmente detrás de Entra Application Proxy). Microsoft tiene la lista de pasos; la parte que más falla es la cuenta de servicio de NDES y el SPN.
2. El certificado raíz en los dispositivos
certutil -ca.cert contoso-root.cer # camino A: exporta la raíz desde la CAcertutil -dump contoso-root.cer | Select-String "Subject:|NotAfter"Subject: CN=Contoso Root CA, DC=contoso, DC=localNotAfter: 14/03/2035 10:02Un perfil de raíz por plataforma (Windows, macOS, iOS/iPadOS, Android Enterprise), con el mismo fichero. Es el que hace que el dispositivo confíe en el RADIUS y en los certificados que va a recibir. Si tu CA emisora es intermedia, también va su certificado en otro perfil.
3. El perfil SCEP
Certificado de dispositivo con el nombre del equipo para Wi-Fi corporativa (el equipo se conecta antes de que nadie inicie sesión); de usuario (CN={{UserPrincipalName}}) para VPN cuando el acceso depende de la persona. El umbral de renovación del 20 % hace que Intune pida uno nuevo cuando quede un quinto de validez: nadie se queda sin Wi-Fi el día que caduca.
4. El perfil de Wi-Fi que lo usa
Tres perfiles encadenados: raíz → SCEP → Wi-Fi. El orden de llegada lo gestiona Intune (el perfil de Wi-Fi espera al certificado), pero en el primer despliegue da margen: asigna raíz y SCEP, espera a ver certificados emitidos, y luego el de Wi-Fi.
5. El certificado que no llega
Get-ChildItem Cert:\LocalMachine\My | Where-Object Issuer -like "*Contoso Device Issuing*" | Select-Object Subject, NotAfter, Thumbprint# (vacío: no hay certificado)Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 200 | Where-Object Message -match "SCEP" | Select-Object -First 3 TimeCreated, Id, MessageTimeCreated Id Message----------- -- -------22/10/2026 09:31:04 32 SCEP: Certificate enroll failed. Result: (The server returned an error: 0x80070005 Access denied). ...Los cuatro sospechosos, en orden:
| Síntoma | Dónde mirar | Causa típica |
|---|---|---|
| Error en el estado del perfil, en todos los dispositivos | Conector de certificados (A) o estado de la CA (B) | Conector caído o cuenta de servicio de NDES con la contraseña caducada |
| Error solo en algunos dispositivos | Evento 32 en el dispositivo | El dispositivo no alcanza la URL de SCEP (proxy, firewall, Application Proxy sin publicar) |
0x80070005 / Access denied | NDES: C:\Windows\System32\certsrv\mscep y plantilla en AD CS | La plantilla no permite "Suministrar en la solicitud" o la cuenta de NDES no tiene Enroll |
| Certificado emitido, Wi-Fi no conecta | Registro del RADIUS/NPS (evento 6273) | El RADIUS no confía en la emisora, o el SAN no coincide con lo que espera |
Lo que no haces: reemitir a mano desde la CA. Si el dispositivo no puede pedirlo solo, tampoco podrá renovarlo.
6. Lo que revisas cada mes
- Perfil SCEP: dispositivos en Error frente a Correcto (
Estado del dispositivo), y la tendencia tras cada cambio de red. - Caducidad de la CA emisora y del certificado del RADIUS: ambos en el calendario con un año de antelación.
- Dispositivos retirados en Intune cuyo certificado sigue válido: con Cloud PKI,
Cloud PKI → la CA → Certificados emitidos → Revocar; con NDES, la revocación en la CA y la CRL publicada. - (Camino A)
Get-Service -Name W3SVC, "Intune Connector Service"en el NDES y la cuenta de servicio en la lista de contraseñas que caducan.
Siguientes pasos
- El mismo certificado de usuario para la VPN (perfil VPN con EAP-TLS) y, con Entra ID, la autenticación basada en certificados (CBA) para quien no puede usar la app Authenticator.
- PKCS en lugar de SCEP cuando el certificado tiene que incluir la clave privada generada por la CA (S/MIME); mismo conector, otro perfil.
- Documenta en Confluence (Nivel 2) la cadena completa: raíz, emisora, URL de SCEP, RADIUS y a quién llamar. Es el runbook que se abre el día que caduque algo.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.
Apúntate y llévate las 33 ideas →