Come configurare SCEP per la registrazione automatica dei certificati WiFi aziendali

Questa guida spiega come configurare SCEP (Simple Certificate Enrollment Protocol) per la registrazione automatica dei certificati WiFi aziendali, coprendo l'intera architettura, da PKI e NDES fino alla distribuzione dei profili MDM e alla convalida RADIUS. Si rivolge a responsabili IT, architetti di rete e CTO di hotel, catene di vendita al dettaglio, stadi, centri congressi e organizzazioni del settore pubblico che hanno l'esigenza di superare le chiavi precondivise e implementare un'autenticazione 802.1X EAP-TLS scalabile e basata sull'identità. La piattaforma cloud overlay di Purple, indipendente dall'hardware, si integra direttamente con questa architettura, fornendo il livello WiFi per ospiti e BYOD che si affianca alla rete del personale autenticata tramite certificato.

📖 10 minuti di lettura📝 2,282 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

Benvenuti alla serie Purple Technical Briefing. Oggi parlerò di un argomento che arriva spesso nelle caselle di posta dei dipartimenti IT, ma che raramente riceve una risposta chiara: come distribuire concretamente l'autenticazione WiFi basata su certificati su larga scala, utilizzando SCEP, all'interno di una rete estesa. Che si tratti di un campus universitario, di un gruppo alberghiero multi-sito o di un grande patrimonio del settore pubblico, le sfide sono identiche.

Copriremo l'intero scenario. Cosa fa effettivamente SCEP, come si inserisce in un'architettura 802.1X, la sequenza di implementazione che la maggior parte dei team sbaglia, due scenari di implementazione reali e le insidie che vi costeranno un intero fine settimana se non le pianificate in anticipo.

Questo è un briefing di consulenza, non un tutorial. Presumo che sappiate cos'è un server RADIUS e che abbiate probabilmente già deciso di abbandonare le chiavi pre-condivise. Ciò di cui avete bisogno ora è la mappa di implementazione.

Entriamo nel vivo.

Primi principi. SCEP sta per Simple Certificate Enrollment Protocol. È stato formalizzato dall'IETF come RFC 8894 nel 2020, sebbene fosse già ampiamente utilizzato a livello aziendale da oltre un decennio. Il suo compito è semplice: automatizzare il processo di installazione di un certificato digitale su un dispositivo gestito senza richiedere l'intervento umano su ogni singola macchina.

Nel contesto dell'autenticazione WiFi, SCEP è il meccanismo di distribuzione. Il protocollo di autenticazione effettivo che state targettizzando è EAP-TLS (Extensible Authentication Protocol con Transport Layer Security), che si colloca all'interno del framework 802.1X. EAP-TLS è ampiamente considerato come il metodo di autenticazione più sicuro per le reti wireless aziendali perché richiede sia al dispositivo client che al server RADIUS di presentare certificati validi. Nessuna delle due parti si fida dell'altra senza una prova crittografica. Questa autenticazione reciproca è ciò che vi protegge dagli attacchi "evil twin", in cui un utente malintenzionato attiva un access point canaglia per sottrarre credenziali.

Ecco come funziona l'intera catena. Un dispositivo gestito, come il laptop di uno studente, il telefono del personale o un terminale POS di un hotel, deve connettersi alla rete wireless aziendale. La vostra piattaforma MDM, che potrebbe essere Microsoft Intune o Jamf, invia un payload SCEP a quel dispositivo. Il payload contiene due elementi: l'URL SCEP, che punta al vostro server NDES o gateway SCEP cloud, e una password di verifica o segreto condiviso.

Il dispositivo genera localmente la propria coppia di chiavi pubblica e privata. Questo passaggio è fondamentale. La chiave privata non lascia mai il dispositivo. Viene generata sul dispositivo, memorizzata nell'enclave sicura o nel TPM, e non viene mai trasmessa sulla rete. Il dispositivo crea quindi una richiesta di firma del certificato, un CSR, e la invia al gateway SCEP. Il gateway convalida la richiesta, inoltra il CSR alla vostra Autorità di Certificazione (CA), e la CA lo firma restituendo il certificato pubblico al dispositivo.

Da quel momento in poi, quando il dispositivo si connette al tuo SSID WiFi, presenta quel certificato al server RADIUS. Il server RADIUS convalida il certificato rispetto alla tua catena di attendibilità della CA, controlla la Certificate Revocation List per confermare che il certificato non sia stato revocato e, se tutto è in regola, invia un messaggio di accettazione all'access point. Il dispositivo è in rete. L'intero processo è invisibile all'utente.

Ora, parliamo di dove si colloca SCEP rispetto all'alternativa, ovvero PKCS. PKCS, Public Key Cryptography Standards, è l'altro metodo di distribuzione dei certificati supportato da piattaforme come Intune. Con PKCS, la CA genera sia la chiave pubblica che quella privata a livello centrale, e il connettore del certificato invia la coppia di chiavi al dispositivo. Ciò significa che la chiave privata viaggia sulla rete, il che introduce una superficie di attacco teorica. PKCS va bene per casi d'uso come la crittografia delle e-mail S/MIME, dove il deposito delle chiavi è effettivamente auspicabile. Per l'autenticazione WiFi, SCEP è la scelta giusta. La chiave privata rimane sul dispositivo, senza eccezioni.

Ora, il livello hardware. SCEP ed EAP-TLS sono standard indipendenti dal fornitore, il che significa che funzionano su access point Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. La configurazione RADIUS, che si tratti di Windows NPS, FreeRADIUS o di un servizio RADIUS cloud, è il luogo in cui si definisce la policy di convalida dei certificati e, soprattutto, in cui si configura l'assegnazione dinamica delle VLAN.

Le VLAN dinamiche consentono di segmentare la rete in base all'identità. Un dispositivo per studenti ottiene la VLAN 20 solo per l'accesso a Internet. Un dispositivo per docenti ottiene la VLAN 10 per l'accesso ai sistemi di ricerca interni. Un dispositivo per la gestione delle strutture ottiene la VLAN 30 per l'accesso ai sistemi di gestione dell'edificio. Tutto questo è guidato dagli attributi del certificato e dalla policy RADIUS, senza alcun intervento manuale per singolo dispositivo.

Per l'integrazione con l'identity provider, gli attributi del certificato SCEP, in particolare il Subject Alternative Name, possono contenere il nome principale dell'utente da Microsoft Entra ID, Okta o Google Workspace. Questo lega il certificato a un'identità specifica, il che significa che quando si disabilita un account in Entra ID e l'MDM annulla la registrazione del dispositivo, il certificato viene revocato e l'accesso WiFi viene interrotto automaticamente. Questa è la gestione della revoca che le chiavi pre-condivise semplicemente non possono offrire.

Bene, parliamo della sequenza di distribuzione, perché è qui che la maggior parte dei team commette errori.

La sequenza non è negoziabile: prima il certificato Trusted Root, poi il profilo del certificato SCEP, infine il profilo WiFi. Sia Intune che Jamf impongono dipendenze tra i profili. Se il tuo profilo WiFi fa riferimento a un certificato SCEP che non è ancora stato distribuito sul dispositivo, il profilo WiFi fallirà con un errore criptico che sembra una configurazione errata ma che in realtà è solo un problema di tempistica.

Il secondo errore comune è il targeting dei gruppi. Tutti e tre i profili, Trusted Root, SCEP e WiFi, devono essere distribuiti esattamente allo stesso gruppo Azure AD o Jamf. Se il profilo SCEP è destinato a un gruppo di utenti e il profilo WiFi a un gruppo di dispositivi, Intune non sarà in grado di risolvere la dipendenza e il profilo WiFi risulterà come Non applicabile. Questo è un errore in cui i team incorrono costantemente.

Terzo: l'accessibilità del server NDES. Il server NDES deve essere raggiungibile da Internet in modo che i dispositivi possano registrarsi prima di arrivare in sede. Il modo corretto per farlo è tramite Azure AD Application Proxy, non aprendo una porta nel firewall. App Proxy offre un accesso remoto sicuro senza porte in entrata e consente di applicare criteri di accesso condizionale al flusso di registrazione.

Quarto: la disponibilità della CRL. Il server RADIUS controlla la Certificate Revocation List ogni volta che un dispositivo si autentica. Se il CRL Distribution Point non è disponibile, a causa di un server offline o di un URL modificato, l'autenticazione fallisce contemporaneamente per tutti i dispositivi della rete. Questo si traduce in un disservizio per l'intera sede. Assicuratevi che gli endpoint CRL siano altamente disponibili e testate la revoca prima di andare online.

Per le reti di grandi dimensioni, con più di 500 dispositivi, prendete in considerazione un gateway SCEP cloud anziché un NDES on-premises. I gateway cloud eliminano il single point of failure di NDES, scalano orizzontalmente e in genere si integrano direttamente con i servizi RADIUS cloud, rimuovendo un'ulteriore dipendenza infrastrutturale.

Rispondiamo ora ad alcune domande rapide che riceviamo spesso dai CTO.

SCEP può gestire i dispositivi BYOD non registrati in un MDM? Non direttamente. SCEP richiede la registrazione MDM per inviare il payload del certificato. Per i dispositivi BYOD non gestiti, è necessario un approccio diverso, come un portale di onboarding self-service o un SSID separato che utilizzi un Captive Portal con verifica dell'identità. Purple gestisce questo livello di ospiti e BYOD in modo pulito, affiancandosi alla rete del personale autenticata tramite certificato.

E per quanto riguarda iOS e Android? Entrambe le piattaforme supportano SCEP nativamente. iOS supporta SCEP fin da iOS 4. Android Enterprise supporta SCEP tramite Intune e altri MDM. La configurazione varia leggermente a seconda della piattaforma, ma il protocollo sottostante è identico.

EAP-TLS funziona con WPA3? Sì. WPA3-Enterprise impone la modalità di sicurezza a 192 bit per gli ambienti sensibili ed EAP-TLS è pienamente compatibile. Di fatto, WPA3-Enterprise con EAP-TLS è la combinazione raccomandata dalla Wi-Fi Alliance per le reti governative e finanziarie.

Per riassumere. L'autenticazione WiFi con certificato SCEP è l'architettura corretta per qualsiasi rete con più di 50 dispositivi gestiti. Elimina le credenziali condivise, fornisce un'identità per singolo dispositivo, consente la segmentazione dinamica delle VLAN e si integra direttamente con l'identity provider per la revoca automatizzata. La sequenza di distribuzione (Trusted Root, poi profilo SCEP, infine profilo WiFi) è fissa. Il targeting dei gruppi deve essere coerente. La disponibilità della CRL non è opzionale.

Specificamente per l'istruzione superiore, la combinazione di SCEP per i dispositivi del personale e dei docenti, insieme a un livello di guest WiFi separato per gli studenti sui dispositivi personali, offre sia sicurezza che un'ottima esperienza utente senza compromessi.

Se desideri approfondire, la guida di Purple sull'autenticazione WiFi aziendale copre il percorso cloud-native. E se stai pensando a cosa succede quando un dipendente lascia l'azienda, la nostra guida sulla revoca dell'accesso WiFi illustra l'intero flusso di lavoro di revoca.

Grazie per l'attenzione. Faccio parte del team tecnico di Purple e ci vediamo al prossimo briefing.

Punti chiave

✓SCEP (RFC 8894) automatizza la registrazione dei certificati per i dispositivi gestiti: la chiave privata viene generata sul dispositivo e non viene mai trasmessa, rendendolo la scelta corretta per l'autenticazione WiFi rispetto a PKCS.
✓La sequenza di distribuzione non è negoziabile: prima il certificato Trusted Root, secondo il profilo del certificato SCEP, terzo il profilo WiFi. La violazione di questo ordine causa errori di dipendenza del profilo.
✓Tutti e tre i profili MDM (Trusted Root, SCEP, WiFi) devono avere come target lo stesso identico gruppo di directory. Il targeting tra gruppi diversi è la causa più comune di errori di distribuzione.
✓NDES dovrebbe essere pubblicato tramite Azure AD Application Proxy, non esposto direttamente a Internet. Per le reti con più di 500 dispositivi, un gateway SCEP cloud elimina il singolo punto di errore di NDES.
✓La disponibilità del CRL Distribution Point è una dipendenza critica per la rete. Se il server RADIUS non riesce a raggiungere la CRL, si blocca in modalità protetta e nega contemporaneamente tutte le autenticazioni.
✓EAP-TLS con certificati forniti tramite SCEP soddisfa il requisito 8.6 di PCI DSS 4.0 per le reti wireless negli ambienti di dati dei titolari di carta ed è richiesto per WPA3-Enterprise a 192 bit (Suite B).
✓SCEP copre solo i dispositivi gestiti. I dispositivi BYOD non gestiti e gli ospiti richiedono un SSID separato con Captive Portal e verifica dell'identità: la piattaforma di Purple gestisce questo livello insieme alla rete del personale autenticata tramite certificato.

Sintesi per il management

Per le grandi strutture aziendali - che si tratti di un hotel da 200 camere, di una catena retail con 50 punti vendita o di un importante centro congressi - affidarsi a chiavi precondivise per il WiFi del personale rappresenta un rischio per la sicurezza e un collo di bottiglia operativo. Una singola password trapelata espone l'intera rete. L'autenticazione basata su certificati tramite IEEE 802.1X ed EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina completamente questo rischio. Ogni dispositivo dimostra la propria identità crittograficamente prima che l'access point conceda l'accesso alla rete.

La vera sfida è la distribuzione. Distribuire manualmente certificati client univoci a migliaia di dispositivi Windows, iOS e Android non è fattibile. Il protocollo SCEP (Simple Certificate Enrollment Protocol), formalizzato come RFC 8894 dall'IETF nel 2020, risolve questo problema. Automatizza il processo di richiesta, emissione e installazione dei certificati digitali sui dispositivi gestiti tramite la tua piattaforma MDM, senza alcuna interazione da parte dell'utente.

Questa guida copre l'intera architettura: cosa fa SCEP, come si integra con Microsoft Intune, Jamf e altre piattaforme MDM, l'esatta sequenza di implementazione che la maggior parte dei team sbaglia e le insidie operative che causano interruzioni del servizio. Analizzeremo anche due scenari di implementazione reali nei settori hospitality e retail, e spiegheremo come la piattaforma Guest WiFi di Purple si affianca alla rete del personale autenticata tramite certificato.

Ascolta il podcast di approfondimento correlato:

Approfondimento tecnico: SCEP, PKI e 802.1X

Cosa fa effettivamente SCEP

SCEP non sostituisce la tua Public Key Infrastructure (PKI). È il livello di registrazione automatizzato che si sovrappone ad essa. La tua PKI - tipicamente una gerarchia a due livelli con una CA root offline e una CA di emissione online - rimane l'ancora di fiducia. SCEP automatizza la fase in cui un dispositivo richiede un certificato a tale CA, eliminando la necessità di generare manualmente CSR e installare certificati.

Nel contesto dell'autenticazione Wi-Fi, il protocollo di destinazione è EAP-TLS. Questo è il metodo di autenticazione 802.1X che richiede sia al dispositivo client che al server RADIUS di presentare certificati X.509 validi. Nessuna delle due parti si fida dell'altra senza una prova crittografica. Questo modello di autenticazione reciproca elimina il furto di credenziali e protegge dagli attacchi "evil twin", in cui un utente malintenzionato crea un access point fittizio per sottrarre nomi utente e password.

Per un'analisi dettagliata dell'handshake EAP-TLS, consulta la nostra guida su WiFi Certificate Authentication: Secure Network Access .

Il flusso di registrazione SCEP, passo dopo passo

La catena di registrazione completa funziona come segue. La tua piattaforma MDM - Microsoft Intune, Jamf o un altro MDM - invia un payload SCEP a un dispositivo gestito. Tale payload contiene due elementi: l'URL SCEP che punta al server NDES (Network Device Enrollment Service) o al gateway SCEP cloud, e una password di verifica (challenge password) o un segreto condiviso.

Il dispositivo genera localmente la propria coppia di chiavi pubblica e privata. Questa è la proprietà di sicurezza fondamentale di SCEP: la chiave privata viene generata sul dispositivo, memorizzata nell'enclave sicura o nel chip TPM e non viene mai trasmessa sulla rete. Il dispositivo crea quindi una richiesta di firma del certificato (CSR) e la invia al gateway SCEP. Il gateway convalida la password di verifica, inoltra la CSR alla Certificate Authority, e la CA la firma restituendo il certificato pubblico al dispositivo.

Da quel momento in poi, quando il dispositivo si connette al tuo SSID WiFi, presenta tale certificato al server RADIUS. Il server RADIUS convalida il certificato rispetto alla catena di attendibilità della CA, controlla la Certificate Revocation List (CRL) per confermare che il certificato non sia stato revocato e, se tutto è in regola, invia un messaggio di Access-Accept all'access point. Il dispositivo è connesso alla rete. L'intero processo è invisibile all'utente.

SCEP vs. PKCS: quale utilizzare per il WiFi

Le piattaforme MDM come Intune supportano due meccanismi di distribuzione dei certificati: SCEP e PKCS (Public Key Cryptography Standards). La differenza architetturale è significativa.

Con SCEP, la chiave privata viene generata sul dispositivo e non lo lascia mai. Con PKCS, la Certificate Authority genera sia la chiave pubblica che quella privata a livello centrale, e il connettore del certificato invia la coppia di chiavi al dispositivo tramite la rete. Ciò significa che la chiave privata viene trasmessa, il che introduce una teorica superficie di attacco.

PKCS è appropriato per i casi d'uso in cui è richiesto il deposito della chiave (key escrow), come la crittografia delle e-mail S/MIME. Per l'autenticazione WiFi, SCEP è la scelta corretta. La chiave privata rimane sul dispositivo.

Proprietà	SCEP	PKCS
Generazione chiave privata	Sul dispositivo (TPM/Secure Enclave)	Centralizzata (CA)
Trasmissione chiave privata	Mai	Via rete
Server NDES richiesto	Sì (o gateway cloud)	No
Consigliato per WiFi	Sì	No
Consigliato per S/MIME	No	Sì

Compatibilità hardware

SCEP e EAP-TLS sono standard indipendenti dal fornitore. Funzionano su access point Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. La configurazione RADIUS - che si tratti di Windows NPS, FreeRADIUS o di un servizio RADIUS cloud - è il luogo in cui si definiscono la policy di convalida dei certificati e l'assegnazione dinamica delle VLAN.

L'assegnazione dinamica delle VLAN consente di segmentare la rete in base all'identità del dispositivo. Un dispositivo del personale ottiene la VLAN 10 con accesso ai sistemi interni. Un dispositivo di un collaboratore esterno ottiene la VLAN 20 con solo accesso a Internet. Un terminale POS ottiene la VLAN 30 con accesso esclusivo ai sistemi di elaborazione dei pagamenti. Tutto questo è gestito dagli attributi dei certificati e dalla policy RADIUS, senza alcun intervento manuale per singolo dispositivo.

Per saperne di più su come WiFi Analytics si integra con la segmentazione di rete basata sull'identità, consulta la panoramica della nostra piattaforma di analytics.

Guida all'implementazione: la sequenza di deployment

La corretta configurazione di SCEP per il WiFi aziendale richiede il rispetto rigoroso di una specifica sequenza di deployment. Le piattaforme MDM impongono dipendenze tra i profili: un profilo WiFi che fa riferimento a un certificato SCEP non può essere applicato finché tale certificato non è presente sul dispositivo. La violazione di questa sequenza è la causa più comune di fallimento del deployment.

La sequenza è: prima il Root attendibile, secondo il profilo SCEP, terzo il profilo WiFi. Questo ordine non è negoziabile.

Passaggio 1: distribuire il profilo del certificato Root attendibile

Prima che un dispositivo possa richiedere un certificato client o considerare attendibile il server RADIUS, deve considerare attendibile l'Autorità di Certificazione (CA) emittente. Esporta il certificato della CA Root - e gli eventuali certificati della CA intermedia - come file .cer. Nel centro di amministrazione MDM, crea un profilo di Certificato attendibile, carica il file .cer e distribuiscilo al gruppo di dispositivi di destinazione.

Se disponi di una gerarchia PKI a due livelli (scelta consigliata), devi distribuire sia il certificato della CA root sia quello della CA emittente come profili di Certificato attendibile separati, o come catena in un unico profilo, a seconda della piattaforma MDM.

Passaggio 2: configurare il profilo del certificato SCEP

Una volta stabilita la relazione di attendibilità, configura il profilo SCEP per indicare ai dispositivi come ottenere il proprio certificato client.

Crea un nuovo profilo di configurazione e seleziona il tipo di profilo certificato SCEP. Configura il formato del Subject name. Per l'autenticazione basata sull'utente, lo standard è CN={{UserPrincipalName}}. Per l'autenticazione del dispositivo (dispositivi condivisi, IoT, terminali POS), utilizza CN={{AAD_Device_ID}}. Imposta Key usage su Digital signature e Key encipherment. Imposta Extended Key Usage su Client Authentication (OID: 1.3.6.1.5.5.7.3.2). Collega questo profilo al profilo del certificato Root attendibile creato al Passaggio 1. Fornisci l'URL esterno del server NDES.Specificamente per Microsoft Intune, il server NDES deve essere pubblicato tramite Azure AD Application Proxy per consentire ai dispositivi remoti di registrarsi prima di arrivare in sede. Non esporre NDES direttamente a Internet.

Passaggio 3: distribuire il profilo WiFi 802.1X

L'ultimo passaggio consiste nel distribuire la configurazione WiFi che associa i certificati al SSID di rete. Crea un profilo di configurazione Wi-Fi. Inserisci il nome della rete (SSID) esattamente come viene trasmesso dai tuoi access point. Seleziona WPA2-Enterprise o WPA3-Enterprise come tipo di sicurezza. Imposta il tipo di EAP su EAP-TLS. Nelle impostazioni di autenticazione, seleziona il profilo del certificato SCEP creato nel Passaggio 2 come certificato di autenticazione client. Specifica il certificato Root attendibile per la convalida del server: questo garantisce che il dispositivo si connetta solo al tuo server RADIUS legittimo e non a un access point non autorizzato.

Integrazione con l'identity provider

Gli attributi del certificato SCEP, in particolare il Subject Alternative Name (SAN), possono contenere il nome principale dell'utente proveniente da Microsoft Entra ID, Okta o Google Workspace. Questo associa il certificato a un'identità specifica. Quando disabiliti un account in Entra ID e l'MDM annulla la registrazione del dispositivo, il certificato viene revocato e l'accesso WiFi viene interrotto automaticamente. Questa revoca automatizzata rappresenta il livello di sicurezza che le chiavi precondivise non possono eguagliare.

Per saperne di più su EAP Method WiFi: A Guide to Secure Network Access , inclusi i percorsi di migrazione PEAP-MSCHAPv2, consulta la nostra guida dedicata.

Best practice e standard di settore

Posizionamento del server NDES

Il server NDES deve essere accessibile da Internet in modo che i dispositivi possano registrarsi prima di arrivare in sede. Pubblica l'URL NDES tramite Azure AD Application Proxy. Ciò fornisce un accesso remoto sicuro senza aprire porte in entrata nel firewall e consente di applicare i criteri di accesso condizionale al flusso di registrazione. Non esporre mai NDES direttamente a Internet.

Per le reti con più di 500 dispositivi gestiti, considera l'utilizzo di un gateway SCEP cloud anziché di un NDES on-premises. I gateway cloud eliminano il single point of failure di NDES, scalano orizzontalmente e in genere si integrano direttamente con i servizi RADIUS cloud.

Disponibilità della CRL

Il tuo server RADIUS controlla la Certificate Revocation List ogni volta che un dispositivo si autentica. Se il tuo CRL Distribution Point (CDP) non è disponibile (perché un server è offline o l'URL è cambiato), l'autenticazione fallisce contemporaneamente per tutti i dispositivi sulla rete. Configura il tuo server NPS o RADIUS per applicare un controllo rigoroso della CRL e rendi i tuoi endpoint CRL altamente disponibili. Testa la revoca prima di andare online.

Il requisito 8.6 di PCI DSS 4.0 impone l'autenticazione a più fattori a livello di rete per gli ambienti con dati dei titolari di carta. EAP-TLS con certificati forniti tramite SCEP soddisfa questo requisito per le reti wireless nei settori Retail e Hospitality .

Compatibilità WPA3

EAP-TLS è completamente compatibile con WPA3-Enterprise. WPA3-Enterprise con la suite di sicurezza a 192 bit (Suite B) richiede obbligatoriamente EAP-TLS ed è la combinazione raccomandata dalla Wi-Fi Alliance per le reti governative, finanziarie e sanitarie. Se la distribuzione avviene in ambienti Sanitari o di Trasporto con rigidi requisiti di conformità, WPA3-Enterprise con EAP-TLS è l'architettura di destinazione corretta.

BYOD e guest WiFi

SCEP richiede la registrazione MDM per inviare il payload del certificato. Non copre i dispositivi BYOD non gestiti o gli ospiti. Per questi casi d'uso, è necessario un SSID separato con un captive portal e la verifica dell'identità. La piattaforma di Purple gestisce questo livello in modo pulito, affiancandosi alla rete del personale autenticata tramite certificato. La nostra piattaforma Guest WiFi supporta l'opt-in a scelta consapevole, l'acquisizione di dati di prima parte e l'integrazione con Microsoft Entra ID, Okta e Google Workspace per la verifica dell'identità.

Risoluzione dei problemi e mitigazione dei rischi

Impossibile applicare il profilo WiFi

Sintomo: Il dispositivo riceve i certificati Trusted Root e SCEP, ma il profilo WiFi viene visualizzato come Errore o Non applicabile nell'MDM.

Causa principale: Mancata corrispondenza del target del gruppo. Se il profilo SCEP si rivolge a un gruppo di utenti e il profilo WiFi a un gruppo di dispositivi, l'MDM non può risolvere la dipendenza.

Soluzione: Controlla le assegnazioni. Assicurati che i profili Trusted Root, SCEP e WiFi si rivolgano tutti esattamente allo stesso gruppo di directory.

Errori NDES 403 Forbidden

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

Causa principale: L'account di servizio MDM Certificate Connector non dispone delle autorizzazioni di Lettura e Registrazione sul modello di certificato, oppure il filtraggio degli URL del firewall blocca i parametri della stringa di query SCEP.

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

Errore di autenticazione di massa dopo la scadenza della CRL

Sintomo: Tutti i dispositivi sulla rete non riescono a autenticarsi contemporaneamente.

Causa principale: La CRL è scaduta o l'URL CDP non è raggiungibile. Il server RADIUS non può confermare la validità dei certificati e si blocca in modalità protetta.

Soluzione: Configura il monitoraggio e gli avvisi per la CRL. Pubblica le CRL con un periodo di validità significativamente più lungo rispetto all'intervallo di pubblicazione. Testa la raggiungibilità del CDP dal server RADIUS prima del go-live.

La scadenza del certificato causa errori silenziosi

Sintomo: I singoli dispositivi non riescono a connettersi in modo intermittente, senza un pattern chiaro.

Causa principale: I certificati client sono scaduti e l'MDM non è riuscito a rinnovarli.

Soluzione: Configura il rinnovo del certificato in modo che si attivi all'80% della durata del certificato stesso. Monitora i report sullo stato di registrazione dell'MDM per i dispositivi con errori di certificato. Imposta periodi di validità dei certificati adeguati al ciclo di aggiornamento dei dispositivi, in genere da uno a due anni per gli endpoint gestiti.

ROI e impatto aziendale

Il passaggio all'autenticazione con certificato 802.1X basata su SCEP offre ritorni misurabili in termini di sicurezza, operazioni e conformità.

Riduzione dei ticket di helpdesk: Il WiFi basato su password genera un volume significativo di ticket di supporto: scadenze delle password, blocchi e refusi. L'autenticazione basata su certificato è invisibile all'utente. Le organizzazioni registrano in genere una riduzione del 70-80% del volume di helpdesk relativo al WiFi dopo la migrazione.

Livello di sicurezza: EAP-TLS elimina la raccolta delle credenziali e gli attacchi Man-in-the-Middle. Ciò supporta direttamente la conformità PCI DSS 4.0 per le reti del settore retail e hospitality, e i requisiti dell'Articolo 32 del GDPR per le misure di sicurezza tecniche adeguate.

Revoca automatizzata: Quando un dipendente lascia l'azienda, la disattivazione del suo account in Microsoft Entra ID attiva la revoca automatica del certificato e la disattivazione del MDM. L'accesso al WiFi viene interrotto senza alcun intervento manuale da parte del team di rete.

Segmentazione della rete: L'assegnazione dinamica della VLAN tramite gli attributi del certificato RADIUS offre una segmentazione della rete applicata crittograficamente. I dispositivi si collegano al segmento di rete corretto in base alle proprietà del certificato, non alla selezione del SSID o al filtraggio degli indirizzi MAC, entrambi facilmente aggirabili.

Purple opera in oltre 80.000 sedi attive con un uptime del 99,999% e la nostra piattaforma è certificata ISO 27001, GDPR, CCPA e Cyber Essentials. Il nostro overlay cloud indipendente dall'hardware si integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet, in modo che la rete del personale autenticata tramite certificato e il nostro livello WiFi per gli ospiti funzionino sulla stessa infrastruttura.

Per ulteriori informazioni su come Behavioral Analytics: Insights for WiFi Networks può integrare la tua implementazione di rete sicura, consulta la nostra guida all'analisi.

Riferimenti

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

Definizioni chiave

SCEP (Simple Certificate Enrollment Protocol)

Un protocollo formalizzato nella RFC 8894 che consente ai dispositivi gestiti di richiedere e ricevere automaticamente certificati digitali X.509 da una Certificate Authority tramite HTTP, utilizzando una password di verifica condivisa per l'autenticazione iniziale. La chiave privata viene generata sul dispositivo e non viene mai trasmessa.

Il meccanismo standard utilizzato dalle piattaforme MDM come Microsoft Intune e Jamf per distribuire certificati di autenticazione WiFi agli endpoint gestiti su larga scala.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Il metodo di autenticazione 802.1X più sicuro, che richiede sia al dispositivo client sia al server RADIUS di presentare certificati X.509 validi. L'autenticazione reciproca implica che nessuna delle due parti si fidi dell'altra senza una prova crittografica.

Il protocollo di autenticazione di riferimento per il WiFi aziendale. Richiesto o fortemente raccomandato da PCI DSS 4.0, WPA3-Enterprise a 192 bit (Suite B) e HIPAA per le reti wireless che gestiscono dati sensibili.

NDES (Network Device Enrollment Service)

Un ruolo di Microsoft Windows Server che funge da Registration Authority (RA) tra i dispositivi abilitati a SCEP e una Certificate Authority. Convalida le password di verifica e inoltra le CSR alla CA per conto dei dispositivi che non dispongono di credenziali di dominio.

Infrastruttura richiesta per la distribuzione di SCEP con Microsoft Intune. Dovrebbe essere pubblicata tramite Azure AD Application Proxy anziché essere esposta direttamente a Internet.

PKI (Public Key Infrastructure)

La gerarchia di Certificate Authority, policy e procedure utilizzate per emettere, gestire e revocare certificati digitali. Una PKI a due livelli è composta da una root CA offline (l'ancora di attendibilità principale) e da una CA di emissione online (che gestisce l'emissione quotidiana dei certificati).

Il prerequisito non negoziabile per la distribuzione di EAP-TLS e SCEP. La CA radice (root CA) deve essere mantenuta isolata (air-gapped); la sua chiave privata è la base dell'intera catena di attendibilità dei certificati.

CSR (Certificate Signing Request)

Un messaggio generato da un dispositivo contenente la sua chiave pubblica e le informazioni di identità, inviato a una Certificate Authority per richiedere un certificato digitale firmato. In SCEP, la CSR viene generata sul dispositivo e racchiusa in una busta PKCS prima della trasmissione.

Generata automaticamente dal dispositivo durante il flusso di registrazione SCEP. La chiave privata utilizzata per firmare la CSR non lascia mai il dispositivo.

CRL (Certificate Revocation List)

Un elenco pubblicato dalla Certificate Authority contenente i numeri di serie dei certificati che sono stati revocati prima della loro data di scadenza. I server RADIUS controllano la CRL a ogni tentativo di autenticazione per garantire che i certificati revocati non possano accedere alla rete.

La disponibilità del CRL Distribution Point (CDP) è fondamentale. Se il server RADIUS non riesce a raggiungere la CRL, si blocca in modalità protetta e nega qualsiasi autenticazione, causando un'interruzione dell'intera rete.

RADIUS (Remote Authentication Dial-In User Service)

Un protocollo di rete che fornisce servizi centralizzati di autenticazione, autorizzazione e contabilità (AAA) per l'accesso alla rete. Nel WiFi 802.1X, il server RADIUS convalida i certificati client, controlla la CRL e restituisce un messaggio di Access-Accept o Access-Reject all'access point.

Il server di autenticazione nel modello supplicant-authenticator-server di 802.1X. Le implementazioni comuni includono Windows NPS, FreeRADIUS e servizi RADIUS in cloud.

Assegnazione dinamica della VLAN

Una funzionalità RADIUS che inserisce un dispositivo autenticato in una specifica VLAN in base agli attributi del certificato o all'appartenenza a un gruppo di directory, anziché affidarsi alla selezione dell'SSID o al filtraggio degli indirizzi MAC. Applica la segmentazione della rete in base all'identità del dispositivo.

Consente a un singolo SSID di servire più tipi di dispositivi con diversi livelli di accesso alla rete. Un dispositivo del personale ottiene la VLAN 10 (accesso interno); un dispositivo di un collaboratore esterno ottiene la VLAN 20 (solo internet); un terminale POS ottiene la VLAN 30 (solo sistemi di pagamento).

MDM (Mobile Device Management)

Software utilizzato dai team IT per registrare, configurare, proteggere e gestire smartphone, tablet e laptop. Le piattaforme MDM come Microsoft Intune e Jamf utilizzano i profili SCEP per inviare le istruzioni di registrazione dei certificati ai dispositivi gestiti senza alcuna interazione da parte dell'utente.

Il prerequisito per la distribuzione dei certificati basata su SCEP. I dispositivi devono essere registrati nell'MDM prima di poter ricevere i profili SCEP e WiFi. I dispositivi BYOD non gestiti richiedono un approccio di onboarding separato.

Esempi pratici

Una struttura Premier Inn da 200 camere deve proteggere la propria rete WiFi del personale per i tablet dei punti vendita e gli smartphone del servizio di pulizia. Attualmente utilizzano una chiave precondivisa che è stata trapelata a collaboratori esterni. Gestiscono i dispositivi tramite Microsoft Intune e hanno un mix di dispositivi iOS e Android. La struttura utilizza access point HPE Aruba.

Distribuire una PKI interna Microsoft AD CS a due livelli. Configurare NDES su un Windows Server dedicato e pubblicarlo tramite Azure AD Application Proxy.
In Intune, creare un profilo di Certificato radice attendibile contenente i certificati della CA radice e della CA emittente. Distribuire a un gruppo Azure AD "Property Staff Devices".
Creare un profilo di Certificato SCEP in Intune che punti all'URL esterno di NDES. Impostare il formato del Nome soggetto su CN={{AAD_Device_ID}} poiché si tratta di dispositivi condivisi. Impostare l'Utilizzo chiave su Firma digitale e Crittografia chiave, e l'Utilizzo chiave avanzato su Autenticazione client. Distribuire a "Property Staff Devices".
Creare un profilo Wi-Fi per l'SSID del personale, configurando WPA2-Enterprise ed EAP-TLS. Selezionare il profilo SCEP per l'autenticazione client e la CA radice per la convalida del server. Distribuire a "Property Staff Devices".
Configurare le impostazioni RADIUS di HPE Aruba in modo che puntino a Windows NPS. Su NPS, configurare un Criterio di rete che richieda EAP-TLS e assegni la VLAN 10 per i dispositivi del personale.
Una volta che i dispositivi ricevono i profili e si connettono correttamente, ruotare la PSK sul vecchio SSID e pianificarne la dismissione.

Commento dell'esaminatore: Questo approccio identifica correttamente che i dispositivi condivisi (POS, servizio di pulizia) richiedono un'autenticazione basata sul dispositivo (CN={{AAD_Device_ID}}) anziché un'autenticazione basata sull'utente, poiché più membri del personale utilizzano lo stesso dispositivo. Segue la sequenza obbligatoria di distribuzione dei profili e garantisce che tutti e tre i profili abbiano come target lo stesso gruppo Azure AD. La pubblicazione di NDES tramite App Proxy anziché l'esposizione diretta a Internet rappresenta la corretta postura di sicurezza per un ambiente ricettivo.

Una catena di vendita al dettaglio con 50 sedi desidera distribuire lo standard 802.1X per i laptop aziendali in tutti i siti. Utilizzano access point Cisco Meraki e Microsoft Intune. Non desiderano distribuire e mantenere server NDES locali o infrastrutture AD CS in ciascuna sede o nel proprio data center.

Implementare una PKI basata su cloud e un servizio gateway SCEP che si integri con Intune tramite il protocollo SCEP. La CA cloud emette i certificati; il gateway SCEP cloud gestisce la convalida CSR.
Configurare il servizio RADIUS cloud (fornito dal fornitore PKI) all'interno della dashboard Cisco Meraki in Wireless > Controllo accessi per l'SSID aziendale. Impostare la sicurezza su WPA2-Enterprise e indirizzare il RADIUS al servizio cloud.
In Intune, creare un profilo di Certificato radice attendibile contenente il certificato radice della CA cloud. Distribuire al gruppo di dispositivi "Corporate Laptops".
Creare un profilo di Certificato SCEP che punti all'URL del gateway SCEP cloud. Impostare il Nome soggetto su CN={{UserPrincipalName}} per l'autenticazione basata sull'utente. Distribuire a "Corporate Laptops".
Creare un profilo Wi-Fi per l'SSID aziendale con EAP-TLS, facendo riferimento al profilo SCEP e alla radice della CA cloud. Distribuire a "Corporate Laptops".
Quando i laptop si registrano in Intune, richiedono automaticamente i certificati alla CA cloud tramite il gateway SCEP cloud. Non è richiesta alcuna infrastruttura locale in nessuna delle 50 sedi.

Commento dell'esaminatore: Questa è l'architettura moderna ottimale per ambienti di vendita al dettaglio distribuiti. Sfruttando la PKI cloud e il RADIUS cloud, l'organizzazione elimina la necessità di mantenere una complessa infrastruttura locale (NDES, AD CS, NPS) in ciascun sito. Il gateway SCEP cloud scala orizzontalmente ed è intrinsecamente ad alta disponibilità, eliminando il singolo punto di guasto introdotto dal NDES locale. L'architettura gestita via cloud di Cisco Meraki si allinea perfettamente con questo approccio.

Domande di esercitazione

Q1. La tua organizzazione sta migrando da PEAP-MSCHAPv2 a EAP-TLS. Hai distribuito con successo i profili Trusted Root e SCEP al tuo gruppo Azure AD "Corporate Users" in Intune. Distribuisci il profilo WiFi a "All Corporate Devices". Gli utenti segnalano che non riescono a connettersi e il profilo WiFi risulta come Non applicabile.

Suggerimento: Verifica le dipendenze del profilo e le regole di targeting del gruppo. Intune risolve le dipendenze del profilo in base al gruppo assegnato.

Visualizza risposta modello

Il problema è una mancata corrispondenza nel targeting dei gruppi. Il profilo WiFi dipende dal profilo SCEP, che è stato indirizzato a un gruppo di utenti ("Corporate Users"). Il profilo WiFi è stato invece indirizzato a un gruppo di dispositivi ("All Corporate Devices"). Intune non può risolvere la dipendenza tra tipi di gruppi diversi. La soluzione consiste nel modificare tutte e tre le assegnazioni dei profili - Trusted Root, SCEP e WiFi - per indirizzarle allo stesso gruppo. Decidi se utilizzare un gruppo di utenti o un gruppo di dispositivi in base al tuo modello di autenticazione (basato su utente o basato su dispositivo) e applicalo in modo coerente a tutti e tre i profili.

Q2. Un audit di sicurezza rivela che quando un dipendente viene licenziato e il suo account Microsoft Entra ID viene disabilitato, il suo smartphone aziendale può ancora connettersi alla rete WiFi del personale fino a una settimana dopo il licenziamento.

Suggerimento: Considera come il server RADIUS determina se un certificato è ancora valido dopo che l'account è stato disabilitato. Qual è il meccanismo per comunicare lo stato di revoca?

Visualizza risposta modello

Il server RADIUS non sta eseguendo un controllo rigoroso della Certificate Revocation List (CRL), oppure la CRL viene pubblicata raramente. Quando un dipendente viene licenziato, l'MDM dovrebbe annullare la registrazione del dispositivo e la CA dovrebbe revocare il certificato. Tuttavia, se il server RADIUS non controlla la CRL a ogni tentativo di autenticazione - o se la CRL viene pubblicata solo settimanalmente - il certificato revocato continua a essere accettato. La soluzione prevede tre passaggi: configurare il server RADIUS per imporre un controllo rigoroso della CRL a ogni autenticazione; configurare la CA per pubblicare la CRL a un intervallo più breve (giornaliero o più frequente); e assicurarsi che l'MDM sia configurato per attivare la revoca del certificato quando un dispositivo viene rimosso dalla registrazione.

Q3. È necessario fornire un accesso WiFi sicuro per dispositivi IoT headless (termostati intelligenti, lettori di segnaletica digitale) che non possono eseguire un agente MDM e non possono visualizzare un Captive Portal. È possibile utilizzare SCEP per questi dispositivi e, in caso contrario, qual è l'alternativa consigliata?

Suggerimento: Considera i prerequisiti per la registrazione SCEP e quali alternative esistono per i dispositivi che non possono essere registrati tramite MDM o che non possono interagire con un browser.

Visualizza risposta modello

Non è possibile utilizzare SCEP per questi dispositivi. SCEP richiede un agente MDM per ricevere l'URL di registrazione e la password di verifica, generare la coppia di chiavi e installare il certificato risultante. I dispositivi IoT headless che non possono eseguire un agente MDM non possono partecipare al flusso di registrazione SCEP. Le alternative consigliate sono: (1) MAC Authentication Bypass (MAB) combinato con una rigorosa segmentazione della VLAN - il server RADIUS consente l'accesso al dispositivo in base al suo indirizzo MAC e lo inserisce in una VLAN IoT isolata senza accesso ai sistemi aziendali; (2) se il dispositivo lo supporta, EST (Enrollment over Secure Transport, RFC 7030) può fornire certificati a dispositivi che supportano HTTPS ma non MDM; (3) per i dispositivi dotati di un'interfaccia di gestione, alcuni fornitori supportano la registrazione SCEP direttamente tramite il firmware del dispositivo senza richiedere un agente MDM. In tutti i casi, i dispositivi IoT dovrebbero essere isolati su una VLAN dedicata, indipendentemente dal metodo di autenticazione utilizzato.

Continua a leggere questa serie

La guida enterprise a SCEP: implementare il Simple Certificate Enrollment Protocol per la sicurezza automatizzata del WiFi nei campus

Questa guida di riferimento tecnico fornisce un modello architetturale definitivo e una strategia di implementazione passo-passo per la distribuzione dei certificati WiFi aziendali tramite SCEP. Copre le differenze cruciali tra SCEP e PKCS, l'esatta sequenza di implementazione necessaria per il successo e le strategie reali di mitigazione del rischio per i leader IT.

Come implementare SCEP per l'assegnazione automatizzata dei certificati WiFi

Questa guida spiega come implementare SCEP (Simple Certificate Enrollment Protocol) per l'assegnazione automatizzata dei certificati WiFi nelle sedi aziendali. Copre l'intero schema architetturale - dalla progettazione PKI e integrazione MDM alla sequenza obbligatoria di implementazione in tre passaggi - e mostra ai manager IT e agli architetti di rete come eliminare le credenziali condivise, automatizzare la gestione del ciclo di vita dei certificati e soddisfare i requisiti PCI DSS e GDPR su scala globale.

Comprendere Cisco SUDI: Identità del Dispositivo Basata su Hardware nel Controllo dell'Accesso alla Rete

Questa guida descrive in dettaglio l'architettura tecnica di Cisco SUDI, spiegando come l'identità ancorata all'hardware protegga il controllo dell'accesso alla rete. Fornisce passaggi di implementazione pratici per i leader IT per distribuire l'autenticazione 802.1X EAP-TLS e automatizzare il Zero Touch Provisioning in tutte le sedi aziendali.