Metodi di registrazione dei certificati

Una proprietà fondamentale dei protocolli di registrazione dei certificati è quindi il modo in cui autenticano chi richiede il certificato. A seconda dell'uso previsto per il certificato, risulta più vantaggioso l'uno o l'altro protocollo.

Un'altra proprietà importante è la diffusione pratica. Il metodo o il protocollo di registrazione deve essere supportato sia dalla CA sia sul lato client per il caso d'uso previsto.

I protocolli di registrazione più diffusi sono:

• SCEP
• ACME
• EST
• RPC/DCOM di Microsoft
• SOAP di Microsoft
• Registrazione manuale sulla pagina web della CA
• Altri protocolli proprietari

SCEP

Storia e specifica

Il Simple Certificate Enrollment Protocol (SCEP) è stato ideato da Cisco. Benché all'epoca non esistesse alcuno standard, si è diffuso ampiamente nei sistemi MDM. Cisco è poi andata oltre e ha progettato un protocollo successore, Enrollment over Secure Transport (EST), destinato a sostituire SCEP. EST è quindi diventato uno standard pubblico con la RFC 7030 molto prima di SCEP, standardizzato solo in seguito nella RFC 8894, quando era già lo standard di fatto per la registrazione dei certificati nei sistemi MDM.

Tecnologia

SCEP si basa su HTTP. Una SCEP Request è un PKCS#7 cifrato e firmato, inviato al servizio SCEP tramite una richiesta GET o POST. Il servizio risponde con una SCEP Response, anch'essa un PKCS#7 cifrato e firmato. La richiesta contiene una richiesta di firma del certificato in formato PKCS#10, la risposta contiene il certificato X.509 emesso.

Autenticazione

La richiesta PKCS#10 contiene una "SCEP Challenge" che autentica e autorizza la richiesta di firma tramite un metodo fuori banda, variabile a seconda dello specifico servizio SCEP. Oggi nella pratica si utilizzano tre tipi di SCEP Challenge:

SCEP Challenge statica

La possibilità più semplice è una passphrase statica. Se la SCEP Challenge contenuta nel PKCS#10 corrisponde a un valore predefinito memorizzato sul servizio SCEP, il certificato viene emesso, altrimenti la richiesta viene rifiutata. Il problema di questo metodo è che non è quasi possibile alcun controllo sulla corrispondenza tra le proprietà richieste per il certificato e il richiedente. Per questo problema esiste persino un CVE.

Questi metodi si possono distinguere ulteriormente:

1. Nel caso di una registrazione SCEP diretta, l'entità per cui va registrato il certificato comunica direttamente con il servizio SCEP. Ad esempio, un sistema MDM indica a uno smartphone Android di effettuare una registrazione SCEP utilizzando la SCEP Challenge "SecurePassword". Lo smartphone Android genera una CSR, auspicabilmente con i valori corretti, e vi aggiunge "SecurePassword" come SCEP Challenge. Invia quindi la CSR al servizio SCEP e riceve in cambio il certificato emesso.
2. Un SCEP Proxy trasparente funziona esattamente come un reverse proxy HTTP. Poiché SCEP è cifrato e firmato, non può realmente esaminare le richieste o le risposte SCEP, né modificarle, ma può controllare chi può registrare certificati e quando, in base ai perimetri di rete.
3. Un SCEP Proxy adattatore di protocollo è un sistema che richiede certificati tramite SCEP per conto di un altro sistema. Ad esempio, un sistema MDM come JAMF potrebbe richiedere un certificato a un servizio SCEP per conto di un iPhone. Una volta ottenuti il certificato e la chiave privata, può distribuire il certificato tramite un altro protocollo. In questo modo solo il sistema MDM ha accesso alla SCEP Challenge e può anche controllare il contenuto del certificato.

SCEP Challenge dinamica

In questo caso ogni SCEP Challenge è valida per una sola richiesta di certificato. Questo consente al servizio SCEP di identificare la richiesta SCEP e di verificare che le proprietà richieste per il certificato corrispondano a quelle consentite per quella specifica richiesta.

Nella pratica si utilizzano in genere due modalità con cui un sistema MDM e una CA SCEP possono concordare la SCEP Challenge da usare per una richiesta:

1. Il sistema MDM, quando ne ha bisogno, richiede al servizio SCEP un codice monouso per una SCEP Request.
   1. Un esempio è Microsoft NDES. NDES dispone di una pagina "admin" separata, autenticata con le credenziali AD. A ogni accesso alla pagina di amministrazione viene creato e mostrato un nuovo codice monouso, utilizzabile per una singola richiesta SCEP. In questa configurazione, però, NDES non verifica alcuna proprietà del certificato, perché il codice monouso è generico.
2. Il sistema MDM genera un codice monouso quando comunica a un sistema gestito di richiedere un certificato tramite SCEP. Quando la SCEP Request arriva al servizio SCEP, il servizio deve recuperare il codice monouso dal sistema MDM, di solito con un web hook, e verificare che corrisponda alla SCEP Challenge presente nella richiesta. Per questo protocollo non esiste uno standard, quindi il sistema MDM e il servizio SCEP devono concordare un formato, e dipende dall'implementazione se le proprietà della richiesta vengono verificate.

Metadati firmati

Per la SCEP Challenge non esiste praticamente alcun limite di lunghezza. Non deve quindi essere per forza una "passphrase" comprensibile per una persona, ma può anche essere un BLOB.

Intune utilizza come SCEP Challenge un XML firmato e cifrato. Lo crea sul lato server e lo invia a un dispositivo client quando vuole registrare un certificato e genera la SCEP Request.

Il servizio SCEP deve inviare l'intera richiesta PKCS#10 a un servizio Intune SCEP Challenge. Il servizio SCEP Challenge dispone della chiave privata per decifrare l'XML e della chiave pubblica per verificare che sia stato creato da un servizio Intune autentico.

L'XML contiene metadati sulla richiesta, ad esempio come deve essere composto il Subject. Questi derivano da un lato dal profilo di configurazione SCEP, dall'altro dai dati specifici dell'oggetto utente o dispositivo per cui il certificato deve essere emesso.

Ad esempio, il profilo di configurazione SCEP potrebbe impostare CN={{DeviceId}} come subject. Quando il dispositivo con id xyz richiede un certificato, l'XML indica che il subject deve essere CN=xyz. Il servizio SCEP Challenge confronta quindi le informazioni dell'XML con il subject presente nella richiesta PKCS#10. La convalida fallisce se i subject differiscono e riesce se questa e le altre proprietà corrispondono.

Il servizio SCEP emette il certificato solo se la convalida riesce.

Microsoft offre un articolo che spiega questa verifica.

Microsoft NDES lo supporta con un modulo di policy NDES aggiuntivo, mentre altre CA SCEP possono supportarlo nativamente oppure no.

Microsoft RPC/DCOM

Storia

Microsoft Active Directory Certificate Services (ADCS), a volte chiamato semplicemente "CA Microsoft", è il software di autorità di certificazione integrato in Windows Server. Il software è stato sviluppato in origine alla fine del millennio scorso e ha continuato a ricevere alcune aggiunte nei dieci o quindici anni successivi.

Un'alternativa è il protocollo SOAP di Microsoft oppure SCEP, che Microsoft chiama rispettivamente Web Enrollment e NDES.

Specifica e diffusione

Non risulta che altri sistemi CA implementino questo protocollo, anche se nel frattempo Microsoft ne ha pubblicato la specifica in Microsoft OpenSpec. Sul lato client, Windows supporta il protocollo in modo nativo, mentre le altre piattaforme non sono supportate.

Tecnologia

Il suo metodo di registrazione principale è un protocollo proprietario basato su RPC o DCOM.

Anche l'autoenrollment utilizza questo protocollo. Perché l'autoenrollment funzioni servono

• un dispositivo aggiunto al dominio.
• Un criterio di gruppo che abiliti l'autoenrollment,
• una CA Enterprise (e non stand-alone)
• che registri un modello di certificato per il quale
• l'utente o il dispositivo dispone delle autorizzazioni di enrollment e autoenrollment.

L'intervallo predefinito per il controllo degli autoenrollment è di 8 ore, anche se lo si può forzare con certutil -pulse o, spesso meglio, con gpupdate -force.

Autenticazione

Questo protocollo utilizza i protocolli di autenticazione integrati in Active Directory, ossia utenti e computer si autenticano con le proprie credenziali AD.