Utforma AD CS-mallar för VPN-gateway- och klientroller

En företags-CA kan utfärda varje certifikat som en VPN behöver utan att någonsin själv vara gatewayen. Designarbetet är att avgöra vad varje part måste bevisa och sedan vilken mall som kan utfärda en legitimation som bevisar just det. Jag börjar med en rolltabell, duplicerar en lämplig mall i stället för att redigera en på plats, fastställer ämnets källa per roll, publicerar resultatet på den utfärdande CA:n och registrerar en pilot innan någon automatiserar det. Varje steg nedan är en plats där en fungerande CA fortfarande producerar ett certifikat som VPN:et kommer att avvisa.

Skriv rolltabellen innan du öppnar mallkonsolen

Två roller, två syften. Gatewayen bevisar en tjänsteidentitet, så dess certifikat behöver Server Authentication (1.3.6.1.5.5.7.3.1), en nyckelanvändning för digital signatur och nyckelkryptering, och värdnamnet som klienterna ringer till i ett alternativt ämnesnamn. Klienter som autentiserar med certifikat behöver Client Authentication (1.3.6.1.5.5.7.3.2) och en identitet som matchar vad gatewayen förväntar sig i sin motpartskontroll. Ett användarcertifikat och ett datorcertifikat är inte utbytbara, eftersom de ligger i olika lager och används av olika processer.

Skriv fyra kolumner per roll: identiteten som måste visas, syftet, nyckelanvändaren och om nyckeln får lämna maskinen. Den tabellen avgör varje kryssruta senare, och den är också det du ger en granskare. Lösenordsbaserad klientautentisering är en egen gren: om gatewayen autentiserar användare med autentiseringsuppgifter tillför distribution av klientcertifikat arbete utan att tillföra bevis.

Duplicera en mall i stället för att redigera en delad

Börja från en mall med ungefär rätt syfte, till exempel RAS and IAS Server för gatewayen eller Computer för domänanslutna enheter, duplicera den sedan och ge kopian ett namn som säger vad den är till för. Att utöka en mall som andra tjänster redan använder är ändringen som förstör något orelaterat sex veckor senare. På kopian ställer du in programprinciperna på syftet från rolltabellen, håller nyckelanvändningen konsekvent med det, väljer nyckelalgoritmen och längden som dina gateways accepterar och markerar den privata nyckeln som icke-exporterbar om inte en apparat behöver exportera den för att flytta den.

Giltighet och förnyelse tillhör också mallen. En kort livstid är lättare att återkalla och svårare att driva; en lång minskar registreringsarbetet och förlänger exponeringen av en läckt nyckel. Välj ett tal du kan försvara och notera att CA:ns egen giltighet och mallens förnyelseperiod kan förkorta resultatet.

Avgör varifrån ämnet kommer

För en domändator eller -användare bygger du ämnet från kataloginformation så att namnet inte kan skrivas av den som begär det. För en gateway som inte är domänansluten, eller en enhet vars identitet tilldelas utanför AD, behöver mallen i stället en kontrollerad begärandeväg. Att aktivera ämne och alternativa namn som begäraren tillhandahåller är ett verkligt beslut: det är inte en licens för varje registrerad att hävda vilket namn som helst, och principen på CA-sidan måste fortfarande säga vem som får fråga och vilket bevis som krävs.

Windows IKEv2 är strikt här. Ett gatewaycertifikat matchas mot namnet som klienten har konfigurerat, så DNS-namnet måste finnas där klienten letar efter det, vanligtvis en dNSName-post i det alternativa ämnesnamnet. Att stänga av namn- eller syfteskontrollen för att få ett icke-matchande certifikat att fungera tar bort kontrollen som skulle ha fångat avvikelsen i produktion.

Publicera mallen och begränsa sedan behörigheterna

Att skapa mallobjektet i AD DS och att publicera det på den utfärdande CA:n är separata åtgärder som görs i olika konsoler. Publicera kopian från Certification Authority-konsolen under Certificate Templates och verifiera sedan från kommandoraden att CA:n nu erbjuder den:

certutil -CATemplates
certutil -TCAInfo

Behörigheterna kommer sedan. Ge Read och Enroll till grupperna som ska begära den och inget mer, håll CA:ns egen läsbehörighet intakt och ge Autoenroll bara där automatisk registrering är avsedd och stöds av distributionsprincipen som får den att fungera. En kryssruta i en mall registrerar inget av sig själv, och en publicerad mall utan registreringsbehörighet ger en portal som listar certifikatet och sedan avvisar begäran.

Registrera en pilot hos den verkliga konsumenten

Begär certifikatet i det sammanhang som ska använda det och undersök sedan vad som kom tillbaka i stället för att lita på filnamnet. Ett användarcertifikat landar i lagret för aktuell användare och ett datorcertifikat i lagret för den lokala datorn, och MMC visar båda, vilket är varför en registrering som “fungerade” fortfarande kan vara osynlig för VPN-tjänsten.

certlm.msc
certutil -dump vpn-gateway.cer

Läs dumpen för ämnet, de alternativa namnen, den utökade nyckelanvändningen och kedjan. För en gateway som inte är Windows skickar du begäran via det stödda arbetsflödet i stället för att anta att domänens automatiska registrering når den, och bekräftar att exportformatet är ett som konsumenten importerar tillsammans med sin matchande privata nyckel. Till sist håller du förtroende och auktorisering åtskilda: VPN:et måste fortfarande avgöra vilka användare eller enheter som når vilka resurser, och återkallelse tar bara bort åtkomst om gatewayen alls kontrollerar återkallelse. Microsofts vägledning för att hantera certifikatmallar täcker mallkonsolen, behörigheterna och det separata publiceringssteget.