Distribuzione dei certificati WiFi di Microsoft Intune tramite SCEP e PKCS

Executive Summary

Per le sedi aziendali—che si tratti di un vivace ambiente Hospitality , di un'operazione Retail multi-sito o di un moderno campus aziendale—affidarsi a chiavi pre-condivise o a Captive Portal di base per il WiFi del personale rappresenta una vulnerabilità di sicurezza e un collo di bottiglia operativo. L'architettura di rete moderna richiede l'autenticazione 802.1X tramite EAP-TLS, garantendo che ogni dispositivo sia verificato crittograficamente prima di accedere alla rete.

Tuttavia, la sfida risiede nella distribuzione: come distribuire certificati client univoci a migliaia di dispositivi Windows, iOS e Android senza sommergere l'helpdesk di ticket di supporto? Microsoft Intune risolve questo problema attraverso la gestione automatizzata del ciclo di vita dei certificati. Sfruttando i profili di certificato SCEP (Simple Certificate Enrollment Protocol) o PKCS (Public Key Cryptography Standards), i team IT possono distribuire silenziosamente certificati root e client attendibili agli endpoint gestiti.

Questa guida fornisce un blueprint architetturale definitivo e una strategia di implementazione passo-passo per la distribuzione dei certificati WiFi di Intune. Esploreremo le differenze critiche tra SCEP e PKCS, dettaglieremo l'esatta sequenza di distribuzione necessaria per il successo e delineeremo strategie di mitigazione del rischio nel mondo reale per garantire che il tuo Guest WiFi e le reti aziendali rimangano sicuri e performanti.

Ascolta il briefing del podcast di accompagnamento:

Technical Deep-Dive: SCEP vs. PKCS

Quando si progetta la strategia di distribuzione dei certificati WiFi di Intune, la prima decisione architetturale è la selezione del meccanismo di consegna dei certificati. Intune supporta sia SCEP che PKCS, ma operano in modo fondamentalmente diverso.

SCEP (Simple Certificate Enrollment Protocol)

SCEP è lo standard di settore per la registrazione dei dispositivi aziendali. In un workflow SCEP, il servizio Intune istruisce l'endpoint a generare la propria coppia di chiavi privata/pubblica. Il dispositivo crea quindi una Certificate Signing Request (CSR) e la invia tramite un server Network Device Enrollment Service (NDES) alla tua Certificate Authority (CA). La CA firma la richiesta e restituisce il certificato pubblico al dispositivo.

Il vantaggio critico in termini di sicurezza di SCEP è che la chiave privata non lascia mai il dispositivo. Viene generata localmente, memorizzata nell'enclave sicura del dispositivo (come il TPM su Windows o il Secure Enclave su iOS) e non viene mai trasmessa sulla rete. Questo rende SCEP l'approccio caldamente raccomandato per l'autenticazione 802.1X.

PKCS (Public Key Cryptography Standards)

Al contrario, con PKCS, la Certificate Authority genera centralmente sia la chiave pubblica che quella privata. Il Microsoft Intune Certificate Connector esporta quindi in modo sicuro questa coppia di chiavi e la invia al dispositivo di destinazione.

Sebbene PKCS elimini la necessità di distribuire e mantenere un server NDES—semplificando l'impronta dell'infrastruttura—introduce un rischio di sicurezza teorico perché la chiave privata viene trasmessa sulla rete. PKCS è generalmente più adatto per casi d'uso in cui è richiesto il deposito delle chiavi (key escrow), come la crittografia e-mail S/MIME, piuttosto che per l'autenticazione di rete.

Implementation Guide: The Deployment Sequence

La configurazione corretta di un profilo WiFi di Intune per 802.1X richiede il rigoroso rispetto di una specifica sequenza di distribuzione. Le dipendenze del profilo Intune impongono che la fiducia debba essere stabilita prima che l'autenticazione possa essere configurata.

Step 1: Distribuzione del profilo del certificato Root attendibile

Prima che qualsiasi dispositivo possa richiedere un certificato client o considerare attendibile il server RADIUS, deve considerare attendibile la Certificate Authority emittente.

1. Esporta il certificato della tua Root CA (e qualsiasi certificato di CA intermedia) come file .cer.
2. Nel centro di amministrazione di Microsoft Endpoint Manager, vai su Dispositivi > Profili di configurazione > Crea profilo.
3. Seleziona la piattaforma di destinazione (ad esempio, Windows 10 e versioni successive) e scegli il tipo di profilo Certificato attendibile.
4. Carica il file .cer e distribuisci questo profilo ai gruppi di dispositivi di destinazione.

Regola empirica: punta sempre agli stessi gruppi (Utenti o Dispositivi) in tutti i profili correlati per evitare discrepanze nella distribuzione.

Step 2: Configurazione del profilo del certificato SCEP

Una volta stabilita la fiducia, configura il profilo SCEP per istruire i dispositivi su come ottenere il loro certificato client.

1. Crea un nuovo profilo di configurazione e seleziona Certificato SCEP.
2. Configura il Formato del nome del soggetto. Per l'autenticazione guidata dall'utente, CN={{UserPrincipalName}} è lo standard. Per l'autenticazione del dispositivo, usa CN={{AAD_Device_ID}}.
3. Imposta l'Utilizzo chiave su Firma digitale e Crittografia chiave.
4. In Utilizzo chiave avanzato, specifica Autenticazione client (OID: 1.3.6.1.5.5.7.3.2).
5. Collega questo profilo al profilo del certificato Root attendibile creato nel Passaggio 1.
6. Fornisci l'URL esterno del tuo server NDES.

Step 3: Distribuzione del profilo WiFi 802.1X

L'ultimo passaggio consiste nell'invio della configurazione WiFi che lega i certificati all'SSID di rete.

1. Crea un profilo di configurazione Wi-Fi.
2. Inserisci il Nome della rete (SSID) esattamente come viene trasmesso dai tuoi Wireless Access Points .
3. Seleziona WPA2-Enterprise o WPA3-Enterprise come tipo di sicurezza.
4. Imposta il Tipo EAP su EAP-TLS.
5. Nelle impostazioni di autenticazione, seleziona il profilo del certificato SCEP creato nel Passaggio 2 come certificato di autenticazione client.
6. Specifica il certificato Root attendibile per la convalida del server per garantire che il dispositivo si connetta solo al tuo server RADIUS legittimo.

Best Practices & Industry Standards

Quando si implementa la distribuzione dei certificati WiFi di Intune, attenersi alle seguenti best practice indipendenti dal fornitore per garantire conformità e affidabilità.

Posizionamento e sicurezza del server NDES

Il server NDES deve essere accessibile da Internet per consentire ai dispositivi remoti di fornire i certificati prima di arrivare in sede. Tuttavia, esporre un server interno direttamente a Internet rappresenta un rischio significativo per la sicurezza.

Raccomandazione: Pubblica l'URL NDES utilizzando Azure AD Application Proxy. Ciò fornisce un accesso remoto sicuro senza aprire porte in entrata nel firewall e consente di applicare criteri di accesso condizionale al flusso di registrazione.

Controllo RADIUS e CRL

La distribuzione dei certificati è solo metà dell'equazione di sicurezza; la revoca è altrettanto critica. Se un dipendente viene licenziato, la disattivazione del suo account Active Directory potrebbe non revocare immediatamente il suo accesso WiFi se il suo certificato client rimane valido e il server RADIUS non controlla rigorosamente la Certificate Revocation List (CRL).

Raccomandazione: Configura il tuo Network Policy Server (NPS) o il server RADIUS per imporre un controllo rigoroso della CRL. Assicurati che i tuoi CRL Distribution Points (CDP) siano altamente disponibili; se il server RADIUS non riesce a raggiungere la CRL, l'autenticazione fallirà, causando un'interruzione diffusa.

Per ulteriori approfondimenti sulla progettazione di reti sicure, consulta I principali vantaggi della SD WAN per le aziende moderne .

Troubleshooting & Risk Mitigation

Anche con una pianificazione meticolosa, la distribuzione dei certificati può incontrare problemi. Ecco le modalità di guasto comuni e le strategie di mitigazione.

Problema: il profilo WiFi non viene applicato

Sintomo: il dispositivo riceve i certificati Root attendibile e SCEP, ma il profilo WiFi appare come 'Errore' o 'Non applicabile' in Intune.

Causa principale: questo è quasi sempre causato da una mancata corrispondenza nel targeting dei gruppi. Se il profilo SCEP è assegnato a un Gruppo Utenti, ma il profilo WiFi è assegnato a un Gruppo Dispositivi, Intune non può risolvere la dipendenza.

Mitigazione: controlla le tue assegnazioni. Assicurati che i profili Root attendibile, SCEP e WiFi siano tutti distribuiti esattamente allo stesso gruppo Azure AD.

Problema: errori NDES 403 Forbidden

Sintomo: i dispositivi non riescono a recuperare il certificato SCEP e i log IIS di NDES mostrano errori HTTP 403.

Causa principale: l'account di servizio Intune Certificate Connector non dispone delle autorizzazioni necessarie sul modello di certificato, oppure il filtraggio degli URL sul firewall sta bloccando i parametri specifici della stringa di query utilizzati da SCEP.

Mitigazione: verifica che l'account del connettore disponga delle autorizzazioni 'Lettura' e 'Registrazione' sul modello della CA. Controlla i log del firewall per assicurarti che gli URL contenenti ?operation=GetCACaps non vengano bloccati.

ROI & Business Impact

Il passaggio alla distribuzione dei certificati 802.1X di Microsoft Intune offre ritorni misurabili in termini di sicurezza e operazioni.

1. Riduzione dei ticket dell'helpdesk: il WiFi basato su password genera un volume significativo di ticket di supporto (scadenze delle password, blocchi, errori di battitura). L'autenticazione basata su certificato è invisibile all'utente, riducendo in genere il volume dell'helpdesk relativo al WiFi del 70-80%.
2. Miglioramento della postura di sicurezza: EAP-TLS elimina il rischio di raccolta delle credenziali e di attacchi Man-in-the-Middle (MitM). Questo è fondamentale per la conformità a framework come PCI DSS e GDPR, in particolare negli ambienti Healthcare e retail.
3. Onboarding fluido: per le organizzazioni che gestiscono grandi flotte di dispositivi Apple insieme a Windows, l'integrazione di Intune con i flussi di lavoro MDM esistenti (vedi la nostra guida su Jamf e RADIUS: autenticazione WiFi basata su certificato per flotte di dispositivi Apple ) garantisce un'esperienza di provisioning zero-touch unificata fin dal primo giorno.