Progettare modelli AD CS per i ruoli di gateway VPN e client

Una CA aziendale può emettere ogni certificato che serve a una VPN senza essere mai essa stessa il gateway. Il lavoro di progettazione consiste nel decidere che cosa deve dimostrare ciascuna parte, e poi quale modello può emettere una credenziale che dimostri esattamente questo. Comincio da una tabella dei ruoli, duplico un modello adatto invece di modificarne uno sul posto, fisso l'origine del soggetto per ruolo, pubblico il risultato sulla CA emittente e iscrivo un pilota prima che qualcuno lo automatizzi. Ogni passaggio qui sotto è un punto in cui una CA funzionante produce ancora un certificato che la VPN rifiuterà.

Scrivete la tabella dei ruoli prima di aprire la console dei modelli

Due ruoli, due scopi. Il gateway dimostra un'identità di servizio, quindi il suo certificato richiede Server Authentication (1.3.6.1.5.5.7.3.1), un utilizzo della chiave per firma digitale e crittografia della chiave, e il nome host che i client contattano in un nome alternativo del soggetto. I client che si autenticano con certificati richiedono Client Authentication (1.3.6.1.5.5.7.3.2) e un'identità che corrisponda a ciò che il gateway si aspetta nel suo controllo della controparte. Un certificato utente e un certificato computer non sono intercambiabili, perché vivono in archivi diversi e sono usati da processi diversi.

Annotate quattro colonne per ogni ruolo: l'identità che deve comparire, lo scopo, il consumatore della chiave e se la chiave può lasciare la macchina. Quella tabella decide poi ogni casella di controllo, ed è anche ciò che consegnate a un revisore. L'autenticazione dei client con password è un ramo separato: se il gateway autentica gli utenti con credenziali, distribuire certificati client aggiunge lavoro senza aggiungere prova.

Duplicate un modello invece di modificare quello condiviso

Partite da un modello con lo scopo all'incirca giusto, come RAS and IAS Server per il gateway o Computer per i dispositivi aggiunti al dominio, poi duplicatelo e date alla copia un nome che dica a che cosa serve. Ampliare un modello che altri servizi già usano è la modifica che rompe qualcosa di non correlato sei settimane dopo. Sulla copia, impostate i criteri applicativi sullo scopo della tabella dei ruoli, mantenete coerente l'utilizzo della chiave, scegliete l'algoritmo e la lunghezza della chiave accettati dai vostri gateway e contrassegnate la chiave privata come non esportabile, a meno che un apparato non debba esportarla per spostarla.

Validità e rinnovo appartengono anch'essi al modello. Una vita breve è più facile da revocare e più difficile da gestire; una lunga riduce il lavoro di iscrizione e allunga l'esposizione di una chiave divulgata. Scegliete un numero che potete difendere, e notate che la validità della CA stessa e il periodo di rinnovo del modello possono accorciare il risultato.

Decidete da dove viene il soggetto

Per un computer o un utente di dominio, costruite il soggetto dalle informazioni della directory, così che il nome non possa essere digitato dal richiedente. Per un gateway non aggiunto al dominio, o un dispositivo la cui identità è assegnata fuori da AD, il modello ha bisogno invece di un percorso di richiesta controllato. Abilitare soggetto e nomi alternativi forniti dal richiedente è una decisione reale: non è una licenza perché ogni iscritto rivendichi un nome qualsiasi, e il criterio lato CA deve ancora dire chi può chiedere e quale prova è richiesta.

Windows IKEv2 è rigoroso qui. Il certificato del gateway viene confrontato con il nome configurato dal client, quindi il nome DNS deve essere presente dove il client lo cerca, di solito una voce dNSName nel nome alternativo del soggetto. Disattivare il controllo del nome o dello scopo per far funzionare un certificato che non corrisponde elimina il controllo che avrebbe colto la discrepanza in produzione.

Pubblicate il modello, poi restringete i permessi

Creare l'oggetto modello in AD DS e pubblicarlo sulla CA emittente sono operazioni separate, eseguite da console diverse. Pubblicate la copia dalla console Certification Authority sotto Certificate Templates, poi verificate dalla riga di comando che la CA ora la offra:

certutil -CATemplates
certutil -TCAInfo

I permessi vengono dopo. Concedete Read ed Enroll ai gruppi che devono richiederlo e nulla più, mantenete intatto l'accesso in lettura della CA stessa e concedete Autoenroll solo dove l'iscrizione automatica è voluta e sostenuta dal criterio di distribuzione che la fa funzionare. Una casella del modello non iscrive nulla da sola, e un modello pubblicato senza permesso di iscrizione produce un portale che elenca il certificato e poi rifiuta la richiesta.

Iscrivete un pilota nel consumatore reale

Richiedete il certificato nel contesto che lo userà, poi esaminate ciò che è tornato invece di fidarvi del nome del file. Un certificato utente finisce nell'archivio dell'utente corrente e uno computer in quello del computer locale, e MMC mostra entrambi, per questo un'iscrizione che “ha funzionato” può restare invisibile al servizio VPN.

certlm.msc
certutil -dump vpn-gateway.cer

Leggete il dump per soggetto, nomi alternativi, utilizzo esteso della chiave e catena. Per un gateway non Windows, inviate la richiesta tramite il flusso di lavoro supportato invece di supporre che l'iscrizione automatica del dominio lo raggiunga, e confermate che il formato esportato sia uno che il consumatore importa insieme alla sua chiave privata corrispondente. Infine, tenete separati fiducia e autorizzazione: la VPN deve ancora decidere quali utenti o dispositivi raggiungono quali risorse, e la revoca toglie l'accesso solo se il gateway controlla la revoca. La guida Microsoft alla gestione dei modelli di certificato copre la console dei modelli, i permessi e il passaggio di pubblicazione separato.