Správa certifikátov a PKI v systéme Windows krok za krokom

Keď organizácia hovorí o overovaní používateľov, zariadení a služieb v prostredí spoločnosti Microsoft, v skutočnosti hovorí o Infraštruktúra verejných kľúčov (PKI), digitálne certifikáty a ich správa v systéme WindowsNie je to triviálna záležitosť: bezpečné fungovanie prihlásení, vzdialeného prístupu, interných webových aplikácií a dokonca aj systémov ako Configuration Manager alebo GIS portál závisí od týchto komponentov.

Dobre navrhnutá PKI v systéme Windows zvyčajne kombinuje Certifikačné služby Active Directory (AD CS), radiče domén, IIS, DNS, skupinové politiky a v mnohých prípadoch aj služby ako AD FS, OCSP alebo cloudové distribučné body.Nasleduje komplexný, podrobný a kontextový sprievodca, ktorý posudzuje, ako je toto všetko organizované: od hierarchie certifikačných autorít až po šablóny certifikátov pre Windows Hello for Business, Configuration Manager, mobilné zariadenia, Mac a interné webové služby.

Základné pojmy: PKI, certifikáty a ich úloha v systéme Windows

V prostredí Windows sa PKI zvyčajne spolieha na hierarchia certifikačných autorít (CA) a certifikátov X.509 vydaných pre používateľov, zariadenia a službyTieto certifikačné autority sa zvyčajne nachádzajú na serveroch so systémom Windows s nainštalovanou rolou AD CS.

Koreňová certifikačná autorita, zvyčajne nezávislý a offlinePôsobí ako konečná kotva dôvery. Pod ňou jedna alebo viacero podnikových vydávajúcich certifikačných autorít, prepojených s doménou, generuje certifikáty na každodenné použitie: autentifikácia pracovných staníc, webové servery, registrační agenti, distribučné body atď.

Systém Windows a aplikácie, ktoré používajú protokoly Kerberos, SSL/TLS, overovanie inteligentnými kartami alebo klientske certifikáty, sa spoliehajú na tieto certifikačné autority, pretože Jeho koreňový certifikát a zoznamy CRL (zoznamy zrušených certifikátov) sú zverejnené na prístupných miestach (LDAP, HTTP, súborový systém)Vďaka tomu môžu tímy overiť reťazec dôvery a skontrolovať, či je certifikát stále platný.

Na tomto základe sú postavené pokročilejšie scenáre, ako napríklad Windows Hello pre firmy s dôverou založenou na certifikátoch, Configuration Manager s klientmi overenými PKI, webové portály integrované so službou Active Directory a overovanie stavu certifikátov prostredníctvom OCSP.

Windows Hello pre firmy a dôveryhodnosť založená na certifikátoch

V modernom firemnom prostredí umožňuje systém Windows Hello for Business používateľom prihlásiť sa pomocou Viacfaktorové prihlasovacie údaje (PIN, biometria) zabezpečené kryptografickými kľúčmiPri výbere modelu dôveryhodnosti certifikátov sa dobre nakonfigurovaná podniková PKI stáva nevyhnutnou.

V tomto modeli Radiče domény potrebujú vhodné certifikáty overovania Kerberos Tieto certifikáty slúžia ako základ dôvery pre klientov. Umožňujú KDC (Key Distribution Center) preukázať svoju identitu doménovým počítačom pomocou modernej kryptografie (aspoň RSA 2048 a SHA256).

V hybridných prostrediach implementácia dôveryhodnosti založenej na certifikátoch pre Windows Hello for Business zvyčajne zahŕňa toto AD FS funguje ako certifikačná autorita (CRA) a podpisuje žiadosti o certifikáty v mene používateľov.Používatelia nakoniec dostanú certifikáty na overenie používateľa, ktoré im umožnia prihlásiť sa do služby Active Directory pomocou ich prihlasovacích údajov Hello.

To si vyžaduje tri kľúčové typy šablón certifikátov: Overovanie Kerberos pre radiče domény, certifikáty registračného agenta pre AD FS a overovacie certifikáty špecifické pre Windows Hello pre firmy.

Laboratórna PKI verzus podniková PKI v produkčnom prostredí

Mnoho organizácií začína s jednoduchým testovacím nastavením pred nasadením finálnej PKI. V laboratórnom prostredí je možné túto inštaláciu vykonať. jedna podniková certifikačná autorita na systéme Windows Server napríklad pomocou PowerShellu:

Pridať funkciu Windows Adcs-Cert-Authority -IncludeManagementTools Nainštaluje rolu certifikačných služieb a potom sa spustí Install-AdcsCertificationAuthority so základnou konfiguráciou.

V reálnom svete je to však oveľa bežnejšie dvojúrovňová hierarchia: nezávislá koreňová certifikačná autorita a podniková vydávajúca certifikačná autoritaKoreňový certifikát je zvyčajne offline, nie je pripojený k doméne a aktivuje sa iba na vydávanie alebo obnovu certifikátov CA a dokonca aj dlhodobých zoznamov CRL. Certifikát vydavateľa je na druhej strane integrovaný so službou Active Directory a spracováva väčšinu denného vydávania certifikátov.

V oboch prípadoch je potrebná starostlivá konfigurácia. trasy AIA (Authority Information Access) a CDP (CRL Distribution Point)ktorý bude označovať, kde je možné získať certifikát CA a zodpovedajúce zoznamy CRL, zvyčajne kombináciou trás:

• Miestna trasa v súborovom systéme (C:\Windows\System32\CertSrv\CertEnroll)
• LDAP v rámci konfiguračnej oblasti služby Active Directory
• HTTP Publikované na serveri IIS, zvyčajne pod aliasom, ako napríklad pki.domain.com/CertEnroll

Certifikáty radiča domény a overovanie Kerberos

Aby tímy mali silnú dôveru v radiče domény, Kerberos „samo o sebe“ nestačí. Je dôležité, aby Každý radič domény musí mať platný certifikát overenia Kerberos.s konkrétnym EKU OID pre túto funkciu.

Klasické šablóny „radič domény“ a „overenie radiča domény“ neobsahujú OID pridané neskôr do RFC Kerberos, takže Odporúča sa vytvoriť novú šablónu založenú na šablóne overovania Kerberos.aktualizácia jeho kryptografie a kompatibility:

• Zlučiteľnosť s Windows Server 2016 v certifikačnej autorite a systéme Windows 10/Server 2016 na strane príjemcu.
• Použitie Poskytovateľ úložiska kľúčov (KSP), algoritmus RSA, minimálna veľkosť 2048 bitov a SHA256.
• Problém vytvorený z Active Directory s Názov DNS zahrnutý v sieti SAN a bez akýchkoľvek ďalších dodatočných identifikátorov.

Po vytvorení šablóny (napríklad „Overenie radiča domény (Kerberos)“) sa označí ako šablóna, ktorá nahrádza starý radič domény a šablóny overenia radiča doményToto sa vykonáva na karte nahradených šablón, takže po publikovaní tejto novej šablóny sa všetky certifikáty založené na predchádzajúcich automaticky nahradia.

Zverejnenie novej šablóny vo vydávajúcom certifikačnom orgáne a zrušenie zverejňovania starých šablón Zabezpečia, aby sa už nevydávali zastarané certifikáty. Potom sa nakonfiguruje a použije objekt GPO na organizačnú jednotku „Radiče domény“, aby sa umožnil automatický zápis certifikátov počítača, aby radiče domény transparentne obnovovali a nahrádzali svoje certifikáty.

Šablóny a certifikáty registračných agentov pre Windows Hello pre firmy

V dôveryhodnej implementácii Windows Hello pre podniky založenej na certifikátoch funguje AD FS ako Autorita registrácie certifikátov (CRA)Na podpisovanie žiadostí o certifikát potrebujú servery AD FS vhodný certifikát registračného agenta.

Zvyčajne začínate so šablónou „Agent zápisu do Exchange (offline žiadosť)“ a vytvoríte duplikát šablóny prispôsobený servisnému účtu používanému službou AD FSExistujú dva typické scenáre:

• Skupinový spravovaný servisný účet (gMSA)Šablóna musí byť nakonfigurovaná s textom „Dodať v žiadosti“ v mene podpisujúceho, pretože gMSA nepodporujú vytváranie predmetu zo služby Active Directory.
• Štandardný servisný účetMôžete použiť možnosť „Kompilovať z týchto informácií služby Active Directory“ s formátom plne kvalifikovaného mena (CN) a zahrnutím UPN do siete SAN.

V oboch prípadoch musí šablóna registračného agenta použiť RSA 2048, SHA256 a poskytovateľ úložiska kľúčova obmedziť registračné povolenia výlučne na účet adfssvc (alebo zodpovedajúci účet), čím sa pre ostatné skupiny zakáže registrácia a automatická registrácia.

Keď sú registrační agenti pripravení, Šablóna overovania systému Windows Hello pre firmyZačnime možnosťou „Prihlásenie pomocou inteligentnej karty“. Niektoré kritické body v jej konfigurácii sú:

• Kompatibilita prispôsobená pre Windows Server 2016 / Windows 10 alebo novší.
• Problém so službou Active Directory, s Celé meno a UPN v sieti SAN.
• Kryptografia s RSA 2048 a SHA256.
• Rozšírenie politiky aplikácií, ktoré zahŕňa prihlásenie pomocou inteligentnej karty.
• Vyžadovať aspoň oprávnený podpis aplikačnej smernice „Agent žiadosti o certifikát“, ktorá zabezpečuje, že certifikáty sa vydávajú iba vtedy, keď je žiadosť podpísaná platným agentom zápisu.
• Vyžiadať kontrolu, ktorá umožňuje obnovenie s rovnakým kľúčom.
• Povolenia na registráciu sú obmedzené na bezpečnostnú skupinu s používateľmi, ktorí budú môcť používať Windows Hello pre firmy.

Nakoniec je táto šablóna označená ako špecifická pre prihlásenie s Hello spustením z príkazového riadka s oprávneniami používateľa certutil.exe -dsTemplate Príznak súkromného kľúča msPKI + CTPRIVATEKEY_FLAG_HELLO_LOGON_KEYVýstup zobrazí staré a nové hodnoty, kde bude pridaný príznak HELLO_LOGON_KEY.

Konfigurácia samoregistrácie a overovania na radičoch domény

Aby si radiče domény a iné počítače mohli obnoviť svoje certifikáty bez manuálneho zásahu, používa sa nasledovné: automatický zápis (automatický zápis) prostredníctvom skupinovej politikyV objekte GPO prepojenom s organizačnou jednotkou radiča domény je povolené nasledovné:

• Obnoviť expirované certifikáty a aktualizovať čakajúce certifikáty.
• Odstráňte zrušené certifikáty.
• Aktualizujte certifikáty, ktoré používajú šablóny certifikátov.

Po použití GPO môžete vynútiť aktualizáciu pomocou gpupdate / force a spustiť registráciu pomocou certreq.exe -autoenroll -qOverovanie sa vykonáva niekoľkými spôsobmi:

• Na kontrolu nových udalostí registrácie a archivácie starých certifikátov použite Prehliadač udalostí v Denníkoch aplikácií a služieb > Microsoft > Windows > CertificateServices-Lifecycle-System.
• certlm.msc zobraziť certifikáty vybavenia v sklade „Personál“ (archivované certifikáty tu však nie sú viditeľné).
• certutil.exe -q -store my alebo s možnosťou -v pre podrobné informácie vrátane EKU, odtlačku prsta a použitej šablóny.

Kľúčom je zabezpečiť, aby Nové certifikáty používajú aktualizovanú šablónu overovania Kerberos pre radiče domény. a ktoré obsahujú očakávané EKU vrátane tých, ktoré sú potrebné na overovanie Kerberos v službe Windows Hello for Business.

PKI a integrované overovanie systému Windows v portáloch a webových aplikáciách

Nejde len o prihlasovanie používateľov a certifikáty počítačov. Mnohé prostredia kombinujú Integrované overovanie systému Windows (Kerberos/NTLM) s klientskymi certifikátmi zvýšiť úroveň zabezpečenia firemných portálov, napríklad v riešeniach ako ArcGIS Enterprise.

V týchto prípadoch sa zvyčajne nasadzuje ArcGIS Web Adaptor na IIS a nakonfigurujte ho na používanie SSL a integrovaného overovania s úložiskom identít služby Active Directory. PKI sa do hry zapojí poskytovaním certifikátov servera a v niektorých prípadoch aj certifikátov klientov na vzájomné overovanie.

Medzi kľúčové kroky patrí:

• Nakonfigurujte portál tak, aby všetka komunikácia by mala prebiehať cez HTTPS.
• Nasmerujte úložisko identít portálu na Používatelia a skupiny služby Active Directory.
• Nainštalujte a povoľte funkciu v službe IIS Autentifikácia priradení klientskych certifikátov služby Active Directory, čo umožňuje mapovanie certifikátov na účty AD.
• Nakonfigurujte webový adaptér tak, aby vyžadoval klientske a SSL certifikáty, a určte, ktorí používatelia môžu vytvárať integrované účty, alebo či sa vynucuje výhradné používanie firemných poverení.

Configuration Manager a jeho integrácia s certifikátmi PKI

System Center Configuration Manager (teraz Microsoft Configuration Manager) naplno využíva podnikovú infraštruktúru veřejných kľúčov (PKI). Rôzne roly (body správy, distribučné body, klienti systému Windows, mobilné zariadenia, Macy) môžu pomocou nej overovať a šifrovať prevádzku. certifikáty vydané certifikačnou autoritou systému Windows.

V typickom príklade laboratória je východiskovým bodom:

• Jedna doména v službe Active Directory so systémom Windows Server 2008 alebo novším.
• Koreňová podniková certifikačná autorita, ktorá vydáva certifikáty v rámci domény.
• Členský server so službou IIS, na ktorom budú nainštalované systémy lokality Configuration Manager.
• Klient systému Windows (napríklad Windows Vista alebo novší) sa pripojil k doméne.

Ide o niekoľko typov certifikátov: Certifikáty webových serverov pre systémy lokalít, klientske certifikáty pre počítače so systémom Windows, exportovateľné certifikáty pre distribučné body (vrátane cloudových), certifikáty pre mobilné zariadenia a pre klientov Mac.

Certifikáty webového servera pre systémy lokalít s IIS

Na ochranu lokalít Configuration Manager v službe IIS, a Bezpečnostná skupina služby Active Directory so servermi IIS, ktoré budú fungovať ako systémy lokalityNapríklad „Servery ConfigMgr IIS“. Potom v konzole šablóny certifikátu CA duplikujte šablónu „Webový server“ a upravte ju takto:

• Dostane popisný názov (napríklad „Certifikát webového servera ConfigMgr“).
• V oblasti zabezpečenia sa odstráni povolenie na registráciu pre správcov domény/podniku a Priraďte registráciu (a čítanie) skupine serverov ConfigMgr IIS.

Šablóna sa publikuje v certifikačnej autorite a certifikát sa vyžiada zo servera IIS pomocou konzoly MMC Certifikáty počítača. Po registrácii sa vyplnia názvy DNS v sieti SAN zodpovedajúce Intranetový a internetový FQDN systému lokality (napríklad server1.internal.contoso.com a server.contoso.com).

Po nainštalovaní certifikátu do osobného úložiska tímu prejdite do Správcu IIS a Prepojte certifikát s väzbou HTTPS predvolenej webovej stránky.Tým sa zabezpečí, že prevádzka klientov do rolí lokality je šifrovaná a že názov, ku ktorému sa klienti pripájajú, sa zhoduje s certifikátom.

Servisné certifikáty pre cloudové distribučné body

Pri používaní cloudových distribučných bodov (Cloud DP) je potrebný certifikát webového servera s exportovateľným súkromným kľúčom, pretože Bude nahrané do cloudu spolu so službouNa tento účel sa šablóna webového servera znova duplikuje:

• Názov šablóny, napríklad „Certifikát distribučného bodu ConfigMgr v cloude“.
• V časti Kontrola požiadaviek je to povolené exportovať súkromný kľúč.
• Povolenia na registráciu udelené skupine serverov lokality ConfigMgr.
• Minimálna veľkosť kľúča v 2048 bitoch.

Po publikovaní si ho server lokality vyžiada od MMC a zadá bežný FQDN cloudovej služby (napríklad clouddp1.contoso.com)Certifikát sa potom exportuje do súboru .PFX, chráni heslom a bezpečne uloží na použitie pri vytváraní distribučného bodu v konzole Configuration Manager.

Klientske certifikáty pre počítače so systémom Windows

Aby sa klienti Configuration Manageru mohli overovať v rolách lokality cez HTTPS, každý počítač potrebuje certifikát overenia klientaBežne sa začína so šablónou „Overenie pracovnej stanice“ a vytvára sa jej kópia, napríklad „Clientský certifikát ConfigMgr“.

Táto šablóna udeľuje Zariadenia riadené doménou majú povolenia na čítanie, registráciu a automatickú registráciu.Publikuje sa pre certifikačnú autoritu a potom sa vytvorí objekt GPO na úrovni domény, ktorý umožňuje automatický zápis certifikátov počítača.

Po použití politiky budú počítače v doméne transparentne vyžadovať klientsky certifikát. V konzole MMC s certifikátmi počítačov môžete overiť, či sa certifikát zobrazuje v úložisku osobných certifikátov za účelom... overenie klienta a šablóna „certifikát klienta ConfigMgr“.

Exportovateľné certifikáty zákazníkov pre distribučné body

Distribučné body Configuration Manager môžu potrebovať exportovateľné certifikáty zákazníkov na overenie totožnosti v iných službách. V tomto prípade sa šablóna „Overenie pracovnej stanice“ znova duplikuje, ale s povolením exportu súkromného kľúča a obmedzením povolení na registráciu na skupinu serverov IIS v nástroji ConfigMgr.

Postup je veľmi podobný cloudovým distribučným bodom: server IIS, ktorý funguje ako DP, si vyžiada certifikát, jeho šablóna sa skontroluje, či je správna a či účel zahŕňa overenie klienta, a potom Exportuje sa do súboru PFX so súkromným kľúčom. importovať ho do konfigurácie DP.

Registračné certifikáty a certifikáty pre mobilné zariadenia a Mac

Keď sa na správu mobilných zariadení používa Configuration Manager, vytvorí sa šablóna pre Registračný certifikát pre používateľov, ktorí budú registrovať zariadeniaZvyčajne je založený na šablóne „Autentifikovaná relácia“ a upravuje sa takto:

• Typ názvu šablóny „Certifikát registrácie mobilného zariadenia ConfigMgr“.
• Problém vytvorený z AD, s bežným názvom a bez UPN v sieti SAN.
• Zaregistrovať povolenia pre skupinu používateľov s povoleniami na registráciu zariadení.

V prípade počítačov Mac sa vykoná niečo podobné: šablóna „Overená relácia“ sa duplikuje a vytvorí sa šablóna ako „Clientský certifikát ConfigMgr Mac“, ktorá priradí Povolenia na registráciu iba skupiny správcov, ktorí budú spravovať registráciu na MacuProblém je opäť vytvorený z AD so spoločným názvom a bez UPN v sieti SAN.

Obe šablóny sa publikujú v certifikačnej autorite a potom sa vyberú v nastaveniach klienta Configuration Manager pri definovaní profilov mobilnej registrácie a možností špecifických pre klienta Mac.

Návrh hierarchie podnikových PKI s offline koreňovou certifikačnou autoritou a vydávajúcou certifikačnou autoritou

V serióznych obchodných prostrediach nie je koreňová certifikačná autorita ponechaná odhalená. Nezávislá koreňová certifikačná autorita, offline, nepripojená k doménea podriadený podnik vydávajúci certifikačnú autoritu, ktorý sa integruje so službou Active Directory.

V koreňovom certifikačnom autorite sa pripraví súbor CAPolicy.inf s parametrami, ako napríklad dĺžka kľúča, doba platnosti certifikátu CA a použitie (alebo nepoužitie) alternatívnych podpisových algoritmovNásledne sa nainštaluje rola AD CS s nezávislým typom CA a koreňovou CA, pričom sa nakonfigurujú dlhé obdobia platnosti (napr. 20 rokov) a príslušné umiestnenia AIA/CDP.

Po inštalácii sa registračné údaje doladia pomocou nástroja certutil: Jednotky CRLPeriod a CRLPeriod (napríklad 52 týždňov), parametre prekrývania CRL, aby sa predišlo medzerám v pokrytí, a maximálna doba platnosti certifikátov vydaných danou certifikačnou autoritou.

Je nevyhnutné aktivovať auditovanie na koreňovej certifikačnej autorite, povoliť prístup k objektom v lokálnej bezpečnostnej politike a nakonfigurovať CA\AuditFilter a 127 Na zaznamenanie všetkých relevantných udalostí v prehliadači udalostí použite nástroj certutil.

Publikovanie AIA a CDP pomocou IIS a DNS

Aby zákazníci mohli získať certifikáty CA a CRL aj mimo internej siete, Webový server IIS, ktorý publikuje HTTP trasy AIA a CDPNapríklad server SRV1 s rolou webového servera a zdieľaným priečinkom C:\CertEnroll.

Priečinok CertEnroll je zdieľaný, čo udeľuje oprávnenia zmena a úprava skupiny vydavateľov certifikátov aby tam certifikačná autorita mohla publikovať svoje zoznamy CRL a certifikáty. V službe IIS sa vytvorí virtuálny adresár „CertEnroll“ smerujúci na C:\CertEnroll a povolí sa prehliadanie adresárov. Okrem toho je v službe IIS povolené dvojité escaping (allowDoubleEscaping), aby sa umožnilo publikovanie delta zoznamov CRL a iných súborov so špeciálnymi znakmi v URL adresách.

V DNS sa vytvorí alias CNAME. pki.domain.com smerujúci na SRV1Toto bude URL adresa používaná v HTTP trasách AIA a CDP. Týmto spôsobom, ak sa v budúcnosti zmenia servery hostujúce CertEnroll, bude možné alias presmerovať bez ovplyvnenia už vydaných certifikátov.

Konfigurácia AIA a CDP v koreňovej certifikačnej autorite a certifikačnej autorite vydavateľa

Umiestnenia AIA a CDP sa nastavujú pomocou nástroja certutil úpravou príslušných kľúčov databázy Registry. Pre AIA sa zvyčajne definujú tri cesty:

• Systém súborov: C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crt
• Kontajner LDAP do AD AIA: ldap:///CN=%7,CN=AIA,CN=PublicKeyServices,CN=Services,%6%11
• verejné HTTP: http://pki.dominio.com/CertEnroll/%1_%3%4.crt

Analogické trasy sú definované pre CDP, smerujúce na Základ a delta CRL v súborovom systéme, LDAP a HTTPa dokonca aj do zdieľaného priečinka na SRV1 na uľahčenie replikácie. Po úprave týchto ciest sa certifikačná služba reštartuje a nový zoznam CRL sa publikuje s príkazom `certutil -crl`.

Vzor sa opakuje vo vydávajúcej certifikačnej autorite, pričom sa zjavne mení názov certifikačnej autority v cestách. Okrem toho sa certifikát vydávajúcej certifikačnej autority skopíruje do priečinka CertEnroll v SRV1, takže cesty HTTP sú platné pre celý reťazec.

Inštalácia vydávajúcej certifikačnej autority a zverejnenie hierarchie

Vyžarujúca striedavá jednotka je nainštalovaná ako podriadená firemná certifikačná autorita na serveri pripojenom k ​​doménePočas inštalácie sa vygeneruje žiadosť o certifikát a odošle sa offline koreňovej certifikačnej autorite, kde sa podpíše a vráti ako certifikát podriadenej certifikačnej autority.

Po vydaní sa certifikát vydávajúcej certifikačnej autority nainštaluje na podriadený server a spustí sa služba certifikačnej autority. Vzhľadom na konfiguráciu súboru CAPolicy.inf vydavateľa je možné, že Nepublikovať predvolené šablóny, čo núti administrátora explicitne vybrať, ktoré šablóny sa budú používať.

Aby bol reťazec viditeľný v celej organizácii, koreňový certifikát CA a jeho zoznam CRL sa publikujú v službe Active Directory pomocou príkazu certutil -dspublish a oba súbory sa skopírujú do priečinka CertEnroll na serveri SRV1, čím sa zabezpečí správne rozpoznávanie ciest LDAP a HTTP v nástrojoch, ako je napríklad PKIView.msc.

Online Response Service (OCSP) a distribúcia stavu zrušenia

Okrem CRL mnoho organizácií používa OCSP na poskytovanie Rýchle overenie stavu zrušenia certifikátuSlužba roly „Online odpovedač“ služby AD CS je nainštalovaná na webovom serveri (napríklad SRV1).

Vydávajúca certifikačná autorita vytvorí šablónu „Podpis odpovede OCSP“ a upraví zabezpečenie tak, aby Stroj SRV1 sa môže zaregistrovaťPotom sa zverejní vydávajúcej certifikačnej autorite, v online odpovedači sa nastaví nová „konfigurácia zrušenia“ a vyberie sa nasledovné:

• Firemná vydávajúca certifikačná autorita ako pôvodca certifikátov.
• Certifikát na podpisovanie odpovedí, ktorý môže byť automaticky vydaný certifikačnou autoritou.
• Poskytovatelia zrušenia, ktorí čítajú zoznamy CRL z LDAP a HTTP, s skrátený interval aktualizácie (napr. každých 15 minút).

Vo vydávajúcom certifikačnom úrade sa do rozšírenia AIA pridá URL adresa OCSP (http://srv1.domain.com/ocsp), pričom sa zaškrtne iba políčko „Zahrnúť do rozšírenia Online Certificate Status Protocol (OCSP)“. Všetky nové certifikáty budú obsahovať URL adresu online odpovedača. bez nutnosti opätovnej registrácie existujúcich, hoci pre tie druhé je možné použiť skupinovú politiku, aby klienti poznali URL adresu OCSP.

Súbor PKIView.msc (Enterprise PKI) sa používa na kontrolu celkového stavu hierarchie: koreňových a vydávajúcich certifikačných certifikátov, základných a delta zoznamov CRL a prítomnosti správnych certifikátov v kontajneroch NTAuth, AIA a CDP služby Active Directory.

Dobre nakonfigurované prostredie PKI v systéme Windows s offline koreňovou certifikačnou autoritou, podnikovou vydávajúcou certifikačnou autoritou, službou IIS na publikovanie AIA/CDP, službou OCSP na overovanie stavu, prispôsobenými šablónami pre radiče domény, službou Windows Hello pre firmy, službou Configuration Manager, mobilnými zariadeniami a zariadeniami Mac a so správne nakonfigurovaným samoregistračným systémom a auditom umožňuje Všetka autentifikácia založená na certifikátoch sa bezproblémovo integruje s Active Directory a podnikovými aplikáciami, čím poskytuje silné zabezpečenie a centralizovanú správu..