Se il tuo PC con Windows 11 Insider/Dev fallisce la registrazione a Intune mostrando “SCEP certificate not found”, questa guida spiega cause, diagnosi e soluzioni: dall’attesa di un fix Microsoft all’implementazione di una CA SCEP in Azure, con best practice di sicurezza e workaround immediati.
Panoramica del problema
Durante l’enrollment di un dispositivo Windows 11 alle policy MDM, alcuni utenti Insider/Developer Build rilevano nel Visualizzatore eventi la voce “SCEP Certificate Enrollment Initialization” seguita da errori come “SCEP certificate not found”. In questo stato l’enrollment Intune non prosegue, i profili di conformità e le Endpoint Security policies non vengono applicati e i log continuano a registrare tentativi falliti di richiesta certificato.
Un’ipotesi plausibile per scenari pre‑rilascio è la temporanea indisponibilità o sostituzione del certificato pubblico usato dal client per stabilire la sessione SCEP. A prescindere dalla causa precisa, l’approccio corretto è: verificare primariamente aggiornamenti/patch Insider, quindi scegliere se attendere la correzione ufficiale o procedere con una propria infrastruttura SCEP (on‑prem/ibrida o in Azure), integrata con Intune tramite profili di certificato.
Come funziona SCEP in breve (e perché può rompersi)
SCEP (Simple Certificate Enrollment Protocol) consente al client di ottenere in modo automatizzato un certificato X.509 da una CA, passando per un endpoint NDES (Network Device Enrollment Service) quando si usa AD CS. In flusso MDM/Intune:
- Il dispositivo riceve un profilo SCEP da Intune (criteri, uso chiavi, durata, URL SCEP, challenge password/token).
- Il client genera una coppia di chiavi, prepara la CSR (PKCS#10) e contatta l’endpoint SCEP.
- La CA emette il certificato secondo il modello assegnato e il client lo installa nello store corretto (Computer o Utente).
Gli errori tipici nascono da uno di questi anelli: catena di fiducia mancante, endpoint SCEP non raggiungibile o senza i prerequisiti, challenge/token invalidi, modelli certificato non idonei, permessi Intune o ruoli insufficienti, o—nelle build Insider—cambiamenti a componenti di sicurezza non ancora allineati.
Piano d’azione rapido
- Verifica aggiornamenti Insider/Dev: prima di tutto, controlla se è disponibile una build o un aggiornamento cumulativo che ripristini la connettività SCEP.
- Controlli di base sul client: stato AAD Join/MDM, reachability URL SCEP, certificati radice/intermedi nello store.
- Valuta l’architettura: attendere fix, spostare temporaneamente a PKCS, oppure implementare una CA SCEP (on‑prem o in Azure IaaS) e integrarla con Intune.
- Applica workaround per ridurre il rumore nei log finché il flusso SCEP non torna operativo.
Diagnostica approfondita lato client
Dove guardare nei log
- Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin.
Filtra per “SCEP”, “certificate”, “enroll”, “NDES”, “challenge”. - Event Viewer → Microsoft-Windows-CertificateServicesClient-AutoEnrollment (per capire se la catena di fiducia è a posto, anche se l’auto‑enrollment AD è un altro meccanismo, dà indizi sulla PKI locale).
Comandi utili
dsregcmd /status
Conferma lo stato Azure AD (AzureAdJoined, MDMUrl, WorkplaceJoined). Se non sei AAD joined o la MDM URL è vuota, SCEP fallirà a prescindere.
certmgr.msc
certlm.msc
Apri gli store utente e computer. Verifica la presenza dei certificati radice/intermedi della CA che emetterà SCEP. Senza catena di fiducia completa l’installazione non andrà a buon fine.
powershell -NoLogo
Test-NetConnection -ComputerName <tuo-endpoint-scep> -Port 443
Invoke-WebRequest https://<tuo-endpoint-scep>/certsrv/mscep/mscep.dll -UseBasicParsing
Verifica reachability e risposta minima dell’endpoint NDES/SCEP (o del servizio SCEP cloud). Attenzione a proxy e DPI.
certutil -verifystore -user ROOT
certutil -verifystore -enterprise ROOT
certutil -store -user My
Controlla catena di fiducia e presenza di eventuali certificati SCEP precedenti con stato “Expired” o “Revoked”.
mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning;DeviceManagement;EPM -cab C:\Temp\MDMDiag.cab
Raccoglie i log MDM in un archivio analizzabile (utile per supporto/forensics).
Indicatori da cercare
- Errori di negoziazione TLS verso l’URL SCEP (proxy, ispezione SSL, ciphers obsoleti).
- Challenge password scaduta o token SAS non valido.
- Template di certificato non compatibile: Key Usage, EKU per autenticazione client, Subject/SAN richiesti (UPN/DeviceID), provider CNG/CSP.
- Permessi: il connettore Intune/NDES deve avere i diritti di “Enroll” sul template.
Verifiche lato Intune e CA
- Ruoli/permessi: l’account che distribuisce profili deve essere Global Administrator o Intune Administrator.
- Profili SCEP: controlla URL, key size (2048/3072), firma RSA, EKU, durata e margine di rinnovo, modalità di challenge (password statica o token rottamabile).
- Certificate Connector (se usi AD CS/NDES): stato del servizio, rinnovo dei certificati connessi, connettività uscente verso Intune.
- NDES: mapping a template corretto, service account con permessi “Enroll” e ACL sul template.
Soluzioni e linee guida emerse
| Passaggio | Dettagli operativi |
|---|---|
| Verificare lo stato del certificato Microsoft | Prima di implementare una CA propria, assicurarsi che non sia disponibile un aggiornamento di Windows 11 Insider che ripristini il certificato SCEP pubblico. Se c’è un cumulative update o un nuovo flight che cita fix MDM/SCEP, installarlo e riprovare l’enrollment (anche re‑avviando il servizio di gestione MDM). |
| Valutare l’uso di una CA SCEP on‑prem o in Azure | On‑prem (NDES + PKI esistente): richiede AD CS, NDES pubblicato via reverse proxy/VPN o connettore; manutenzione patching e apertura porte. Azure IaaS / cloud‑native: VM Windows Server con AD CS e NDES in Azure, esposto in modo sicuro dietro Application Gateway/Front Door; gestione semplificata lato rete e scalabilità elastica. |
| Prerequisiti di ruolo e permessi | L’account che configura Intune deve avere ruoli Global Administrator o Intune Administrator; in alternativa serve il supporto di un amministratore tenant per delegare privilegi o creare un profilo di certificato. |
| Configurazione della CA SCEP in Intune | Preparare la CA (cloud o ibrida) e abilitare l’interfaccia SCEP (NDES) o il servizio SCEP supportato. In Intune → Endpoint security → Certificates → SCEP certificate, definire URL SCEP, challenge (password/token), usages, validità/rinnovo. Associare il profilo ai gruppi di dispositivi/idoneità e monitorare il tasso di successo. |
| Risolvere l’errore attuale | Controllare che l’URL SCEP sia raggiungibile dal client e che non sia bloccato da proxy/SSL inspection. Verificare che il certificato radice/intermedio sia presente nello store Trusted Root del dispositivo. Confermare che la CA riconosca la richiesta e che il template consenta l’autenticazione computer (EKU: Client Authentication). |
| Eventuali workaround temporanei | Disabilitare temporaneamente il profilo SCEP in Intune per evitare log continui. Utilizzare certificati PKCS firmati dalla stessa CA fino a ripristino del flusso SCEP. |
Implementare una CA SCEP in Azure: guida pratica
Se decidi di realizzare una CA “personale” in Azure, punta a una soluzione minimale ma robusta con AD CS e endpoint NDES esposto in modo sicuro. Di seguito un percorso operativo consigliato.
Architettura di riferimento
- CA di emissione (Enterprise Subordinate o Standalone, a seconda del dominio): VM Windows Server in Azure.
- NDES su VM dedicata (consigliato separare CA e NDES per sicurezza e manutenzione).
- Application Gateway/Front Door con WAF per pubblicare in HTTPS l’endpoint
/certsrv/mscep/, terminazione TLS con certificato pubblico attendibile. - Intune Certificate Connector (se si integra un flusso ibrido) o integrazione diretta via URL SCEP.
- Key Vault opzionale per custodire segreti/chiavi, rotazioni e auditing.
Preparazione della CA
- Definisci il modello di certificato per i dispositivi: EKU “Client Authentication”, key size 2048/3072, provider CNG (se necessario), Subject e SAN coerenti con la modalità di autenticazione (DeviceID/UPN).
- Assegna permessi “Enroll” e “Autoenroll” al servizio NDES o al connettore che presenterà le richieste.
- Configura CRL/AIA raggiungibili (HTTP) da Internet o da dove risiedono i dispositivi.
Installazione e hardening di NDES
- Installa il ruolo NDES sulla VM designata e collega il servizio alla CA di emissione.
- Imposta la challenge (password o token time‑based) e il mapping ai template autorizzati.
- Applica hardening:
- Protocollo TLS 1.2+ con suite moderne; disabilita ciphers deboli.
- Limitazione IP (IP allowlist) e protezione WAF.
- Logging dettagliato su Event Viewer e forward a Log Analytics.
Configurazione del profilo SCEP in Intune
- In Endpoint security → Certificates → SCEP, crea un nuovo profilo “Device” per Windows.
- Specifica:
- URL SCEP: lo Fully Qualified Domain Name pubblicato dal tuo Application Gateway.
- Challenge: password rotante o token. Evita segreti statici a lunga durata.
- Key usage: Digital Signature e Key Encipherment se richiesto dal template.
- Hash e algoritmo: SHA‑256, RSA.
- Validità: valuta 1 anno per dispositivi, con rinnovo automatico 30 giorni prima.
- Associa il profilo ai gruppi di dispositivi (Dynamic AAD per deviceCategory o OSVersion utile per isolare le Insider).
- Monitora gli esiti da Reports → Certificates.
Sicurezza: proteggere l’endpoint SCEP
- Posiziona NDES dietro Application Gateway/Front Door con WAF e rate limiting.
- Attiva Azure Monitor/Log Analytics con alert su codici di errore SCEP, fail rate e spike anomali.
- Isola la CA: non pubblicare mai direttamente la CA di emissione su Internet.
- Automatizza la rotazione della challenge/token e dei certificati del servizio.
- Verifica periodicamente CRL/AIA: indisponibilità delle liste di revoca causa errori di validazione lato client.
Workaround temporanei consigliati
- Mettere in pausa il profilo SCEP sulle build Insider/Dev per evitare continui tentativi falliti e rumore nei log.
- Usare profili PKCS (Intune → PKCS certificate) emessi dalla stessa CA finché SCEP non torna stabile. Richiede connettore ma evita l’endpoint SCEP.
- Distribuire temporaneamente certificati radice/intermedi via “Trusted certificate” per risolvere errori di catena, se quello è il collo di bottiglia.
Licensing e requisiti
- Intune: incluso in Microsoft 365 E3/E5 o Business Premium; in alternativa licenza Intune standalone.
- Azure AD Premium P1/P2: consigliato per criteri di sicurezza avanzati, Conditional Access e gestione identità.
- Costi Azure: VM per CA/NDES, Application Gateway/Front Door, Log Analytics. Valuta Reserved Instances o Auto‑stop per contenere spese nei lab.
Gestione del ciclo di vita dei certificati
- Rinnovo automatico a D‑30: imposta la finestra di renew nel profilo SCEP/PKCS.
- Report: usa i report Intune per certificati in scadenza, tasso di successo e dispositivi non conformi.
- Rotazioni pianificate di chiavi server e challenge, con change window comunicata agli utenti.
Approfondimento: perché scegliere SCEP, quando preferire PKCS
SCEP scala bene per flotte ampie, ma si affida a un endpoint “stateless” esposto. PKCS richiede un connettore ma non espone pubblicamente NDES; è spesso più semplice da mettere in sicurezza in ambienti con forti restrizioni di rete. Un approccio ibrido consente di usare PKCS come fallback quando SCEP non è disponibile (ad esempio su Insider/Dev).
Checklist di prerequisiti e permessi
| Elemento | Verifica |
|---|---|
| Ruoli Intune | L’operatore ha ruolo Global/Intune Administrator. |
| Stato dispositivo | dsregcmd /status: AzureAdJoined = YES, MDM enrollment attivo. |
| Catena di fiducia | Root/Intermediate della CA nello store Trusted Root/Intermediate del dispositivo. |
| Reachability | URL SCEP raggiungibile su 443 senza ispezione SSL distruttiva. |
| Template certificato | EKU “Client Authentication”, Key Usage corretti, permessi “Enroll”. |
| NDES / Connector | Servizi in esecuzione, certificati server validi, mapping template corretto. |
FAQ ed errori comuni
| Sintomo | Causa probabile | Risoluzione |
|---|---|---|
| “SCEP certificate not found” su Insider/Dev | Componenti SCEP/MDM non allineati nella build provvisoria | Aggiorna alla build successiva; in alternativa passa a PKCS o usa una tua CA SCEP. |
| Errore TLS verso /mscep/ | Proxy, ispezione SSL o ciphers non supportati | Escludi l’URL SCEP dall’ispezione; forza TLS 1.2+ e suite moderne. |
| Richiesta rifiutata dalla CA | Template non autorizzato o permessi mancanti | Concedi “Enroll” al servizio NDES/connettore sul template; verifica EKU/Key Usage. |
| Certificato installato ma non usato | Store errato o EKU non adatto all’autenticazione | Forza lo store “Computer” se necessario; imposta EKU “Client Authentication”. |
| Catena non attendibile | Root/Intermediate mancanti sul client | Distribuisci profili “Trusted certificate” prima del profilo SCEP. |
Endpoint Protection: cogliere l’occasione
Se decidi di intervenire sull’enrollment, approfitta per rafforzare la postura di sicurezza:
- Antivirus/Next‑gen e EDR con reporting su Intune.
- BitLocker con escrow delle chiavi in AAD, criteri di cifratura XTS‑AES.
- Firewall e ASR (Attack Surface Reduction) per ridurre macro/payload.
- Account Protections: passwordless e Conditional Access, riducendo l’attrito utente.
Implementazione guidata: esempio di profilo SCEP
Ecco un esempio di parametri tipici da tenere come riferimento quando compili il profilo:
Uso chiavi: Digital Signature, Key Encipherment
Algoritmo: RSA, SHA-256
Lunghezza chiave: 2048 o 3072
EKU: Client Authentication (1.3.6.1.5.5.7.3.2)
Subject/SAN: DeviceID o UPN secondo lo scenario
Validità: 12 mesi
Rinnovo automatico: D-30
URL SCEP: https://<fqdn>/certsrv/mscep/
Challenge: token rotante (consigliato)
Store: Computer (se richiesto per VPN/Wi-Fi 802.1X machine)
Monitoraggio e KPI
- Tasso di successo richiesta SCEP per gruppo di assegnazione (obiettivo >98%).
- Tempo medio di emissione tra distribuzione profilo e certificato installato.
- Errori per categoria (TLS, Challenge, Template, Permessi) per priorità d’intervento.
Quando ha senso implementare una CA SCEP personale
Per un singolo PC o un lab Insider la soluzione economicamente migliore è spesso attendere il ripristino ufficiale o usare PKCS come ponte. Una CA propria in Azure è perfettamente fattibile e didattica, ma introduce costi (VM, gateway, monitoraggio) e oneri di manutenzione (patching, CRL, hardening). Se gestisci più dispositivi o vuoi standardizzare l’autenticazione per VPN/802.1X, investire in una PKI gestita ha molto più senso.
Riepilogo operativo
- Controlla aggiornamenti Insider/Dev: potresti risolvere senza cambiare architettura.
- Se ti serve continuità, metti in pausa SCEP e passa a PKCS temporaneamente.
- Se scegli la CA SCEP in Azure, progetta subito hardening, logging e rotazioni.
- Integra Endpoint Protection mentre sistemi l’enrollment per massimizzare il beneficio.
Informazioni supplementari utili
- Documentazione mirata
- “Deploy SCEP certificates with Intune” – guida passo‑passo.
- “NDES Planning and Deployment Guide” – scenari ibridi AD CS.
- Licensing
- CA in Azure: richiede licenze Intune (M365 E3/E5 o Business Premium) e, idealmente, Azure AD Premium P1/P2.
- Sicurezza
- Proteggi NDES con firewall dedicato e posizionalo dietro Application Gateway/Front Door.
- Abilita Logging e Alerts su Azure Monitor per intercettare errori di rinnovo o challenge.
- Gestione del ciclo di vita
- Imposta rinnovo automatico 30 giorni prima della scadenza.
- Usa i report Intune per certificati in scadenza e successo dell’enrollment.
Appendice: comandi e script rapidi
Verifica proxy e WinHTTP
netsh winhttp show proxy
netsh winhttp reset proxy
Elenco certificati client
powershell
Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication" } |
Select-Object Subject, NotBefore, NotAfter, Thumbprint
Eventi MDM/SCEP ultimi 24h
powershell
$since = (Get-Date).AddHours(-24)
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" |
Where-Object { $.TimeCreated -ge $since -and $.Message -match "SCEP|certificate|enroll" } |
Select-Object TimeCreated, Id, LevelDisplayName, Message
Verifica catena per FQDN SCEP
powershell
$host = "<fqdn-endpoint-scep>"
$tcp = New-Object Net.Sockets.TcpClient($host,443)
$ssl = New-Object Net.Security.SslStream($tcp.GetStream(),$false,({$true}))
$ssl.AuthenticateAsClient($host)
$ssl.RemoteCertificate | Format-List Subject,Issuer,NotAfter
Conclusioni
“SCEP certificate not found” su Windows 11 Insider/Dev è un campanello d’allarme che spesso indica una discrepanza temporanea tra componenti di sicurezza di sistema e stack MDM. La soluzione più rapida è verificare un aggiornamento di sistema; in alternativa, ripiega su PKCS o realizza una CA SCEP in Azure con tutte le cautele del caso. L’importante è affrontare il problema in modo strutturato: check preliminari, diagnosi mirata, implementazione sicura e osservabilità costante. Così riduci i tempi di indisponibilità e, nel frattempo, puoi innalzare il livello di protezione del parco dispositivi con le funzionalità di Endpoint Protection.
Da ricordare
- Se la build Insider/Dev non include più il certificato pubblico SCEP, la via più semplice è attendere il ripristino ufficiale o installare un aggiornamento cumulativo.
- Implementare una CA SCEP personale è fattibile e istruttivo ma porta costi e complessità: valuta il rapporto sforzo/beneficio se stai gestendo un singolo PC.